chrony date months off

[gene heskett]

How do I setup /etc/chrony/chrony.conf so it slams the system clock to 
the current time on the first cycle as its rebooting?

There was 20 yeas back, an ntpdate command that would do that.
Now it appears to conflict with the other client/servers

Thanks

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: chrony date months off

[tomas]

On Wed, Jan 31, 2024 at 05:32:26AM -0500, gene heskett wrote:
> How do I setup /etc/chrony/chrony.conf so it slams the system clock to the
> current time on the first cycle as its rebooting?
> There was 20 yeas back, an ntpdate command that would do that.
> Now it appears to conflict with the other client/servers

I think you want "maxstep". It's in the man page chrony.conf(5).

But if the time is "months off" perhaps you've got another problem
to fix first?

You wouldn't want chrony to slam your clock just because its only
reachable server runs amok. Just sayin'.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: os-prober detects in wrong order and GRUB doesn't have enough options

[Greg Wooledge]

On Wed, Jan 31, 2024 at 05:29:56AM -, David Chmelik wrote:
> Earlier this or last year I tried to use Devuan to report os-prober 
> detects in wrong order.  It may detect current OS partition first, but if 
> you have more than 10, then it continues from 10, and (if this is all you 
> have) goes to the last in the tens but then continues somewhere in single-
> digit partitions,

Sounds like someone's doing an alphanumeric sort on numbers.

unicorn:~$ printf '%s\n' 1 2 3 11 12 13 | sort
1
11
12
13
2
3

It could be a result of filename globbing, e.g. /dev/sda[0-9]* which
would give that kind of ordering.

In any case, this isn't a Devuan mailing list.  If you've reported a
bug to Debian, then you should have the bug number, and the URL to
its web page.  If you've reported it to Devuan, then we can't help.

Re: chrony date months off

[Max Nikulin]

On 31/01/2024 17:54, to...@tuxteam.de wrote:

I think you want "maxstep". It's in the man page chrony.conf(5).

But if the time is "months off" perhaps you've got another problem
to fix first?


I think, the problem is no RTC on some *pi board, certainly chrony out 
of box setup is not ready to such environment and its solution is not 
maxstep.


Gene, are you going to complain again that some package has no man pages?

Re: chrony date months off

[didar]

On Wed, Jan 31, 2024 at 05:32:26AM -0500, gene heskett wrote:
> How do I setup /etc/chrony/chrony.conf so it slams the system clock to the
> current time on the first cycle as its rebooting?
> There was 20 yeas back, an ntpdate command that would do that.
> Now it appears to conflict with the other client/servers

You can use "rdate" (openrdate) as quick fix like `ntpdate'. I resort to using
it inside my virtual machines on my laptop when it wakes up from hibernation.

I use chrony on my production MTAs on the internet though.

-- 
Regards,
Didar

Worlds are conquered, galaxies destroyed -- but a woman is always a woman.
-- Kirk, "The Conscience of the King", stardate 2818.9

Generated by Signify v1.14 (http://www.debian.org/)

Re: chrony date months off

[John Hasler]

Gene writes:
> How do I setup /etc/chrony/chrony.conf so it slams the system clock to
> the current time on the first cycle as its rebooting?

initstepslew

man chrony.conf
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

AW: AW: su su- sudo dont work

[Schwibinger Michael]

Good afternoon
I think
maybe Im sure
it is because of rescue mode.

Normal booting did not have this problem.

Anybody familiar with panic?

Regards
Thank You
Sophie



Von: Andrew M.A. Cater 
Gesendet: Donnerstag, 25. Januar 2024 18:40
An: debian-user@lists.debian.org 
Betreff: Re: AW: su su- sudo dont work

On Thu, Jan 25, 2024 at 03:53:10PM +, Schwibinger Michael wrote:
> Good afternoon
> Why do I have to open a group?
>

This is to *tell* us information about why you're having problems with su
and sudo

Running the

id

command should give you information like

uid=1000(amacater) gid=1000(amacater) groups=1000(amacater),27(sudo)

which shows you that my user - amacater - is the first user on the
machine (because Debian starts user id numbers at 1000 for ordinary
users) and that I'm a member of group sudo - so can use sudo instead of su.

/etc/sudoers will show you what privileges the sudo user has.
Here are the last lines of the file on my machine (which has not been
modified from Debian defaults)

# User privilege specification
rootALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "@include" directives:

@includedir /etc/sudoers.d
(END)

If you are _not_ a user of group sudo for whatever reason - and want to
use sudo - then you will need root privileges and the root password
(once) to add your user name to the group.

For example: adduser sophie sudo

I hope this helps

> 2 years ago
> sudo was no problem.
>

As yet, we have *no idea* what you have done in the last two years to
break your Debian system - or even to know which kernel you boot or
how you "rescue" your system when you log onto it every day.

Please give us information in order that the readers on this list can
use their knowledge to help you.

With every good wish, as ever,

Andy
(amaca...@debian.org)
> Regards
>
> Sophie
>
> Thank You
> 
> Von: Timothy M Butterworth 
> Gesendet: Montag, 22. Januar 2024 00:07
> An: Schwibinger Michael 
> Cc: Greg Wooledge ; debian-user@lists.debian.org 
> 
> Betreff: Re: su su- sudo dont work
>
>
>
> On Sun, Jan 21, 2024 at 4:07 PM Schwibinger Michael 
> mailto:h...@hotmail.com>> wrote:
> Thank You
> Example
> I say
>
> sudo apt-get install firefox
> Reaction LINUX
> This is not allowed we send a message to the admin.
>
> This error message means that your account is not in the sudo group.
>
> Run the command "groups" and look for the group sudo.
> groups
>
> Here is the command to add a user account to the sudo group. You will need to 
> run it as root.
> usermod -a -G sudo 
>
> I do open root terminal
> there its working.
> Regards
> Sophie
>
> 
> Von: Greg Wooledge mailto:g...@wooledge.org>>
> Gesendet: Samstag, 20. Januar 2024 14:14
> An: debian-user@lists.debian.org 
> mailto:debian-user@lists.debian.org>>
> Betreff: Re: su su- sudo dont work
>
> On Sat, Jan 20, 2024 at 01:26:06PM +, Schwibinger Michael wrote:
> > Good afternoon.
> > Root terminal is fine.
> > What do I do wrong?
> > What did I destroy?
> >
> > PC does have only one user=admin.
> >
> > Regards Sophie
> > Is it the rescue mode?
>
> Explain, please.
>
> Your Subject: header says "su su- sudo dont work".  What does this MEAN?
>
> Please show us your attempts to USE each of these commands, and the
> results that you got.  This means, run the commands in a terminal
> window, and then PASTE the contents of that terminal window into the
> body of your next email.  Show us the shell prompt, the command as you
> typed it, and the full output.
>
> In other words, show us WHAT IS WRONG, or at least what appears wrong.
>
> In addition, please give basic background information -- what version
> of Debian you are running, what desktop environment if any, how you
> logged in (*especially* if it isn't just a "standard graphical login
> for your desktop environment"), and anything else you can think of
> that might be relevant.
>
> How does "rescue mode" factor into the problem?
>
> When you installed Debian, did you give a root password, or did you
> leave it blank?
>
> Finally, it would be helpful for you to run the "id" command (with no
> arguments), in the same terminal session as your failed su or sudo
> command(s), and include that command and its output in your paste.
>
>
>
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
> ⠈⠳⣄⠀⠀

Re: chrony date months off

[Greg Wooledge]

On Wed, Jan 31, 2024 at 07:53:01AM -0600, John Hasler wrote:
> Gene writes:
> > How do I setup /etc/chrony/chrony.conf so it slams the system clock to
> > the current time on the first cycle as its rebooting?
> 
> initstepslew
> 
> man chrony.conf

Debian 12 has chrony 4.3, and in *that* version of the man page, it
says initstepslew is deprecated in favor of makestep.

https://chrony-project.org/doc/4.3/chrony.conf.html#makestep

Re: Can't list root directory

[Gary Dale]

On 2024-01-30 15:54, hw wrote:

On Mon, 2024-01-29 at 11:42 -0500, Gary Dale wrote:

I'm running Debian/Trixie on an AMD64 workstation. I've lost the ability
to see the root directory even when I am logged in as root (su -).

This has been happening intermittently for several months. I initially
thought it might be related to failing NVME drive that was part of a
RAID1 array that is mounted as "/" but I replaced the device and the
problem is still happening.
[...]

What happens when you put the device you replaced back?

How could putting a known-failing device back in help? The problem 
existed before I replaced it and continues to exist after the replacement.

Re: Can't list root directory

[Gary Dale]

On 2024-01-29 11:42, Gary Dale wrote:
I'm running Debian/Trixie on an AMD64 workstation. I've lost the 
ability to see the root directory even when I am logged in as root (su 
-).


This has been happening intermittently for several months. I initially 
thought it might be related to failing NVME drive that was part of a 
RAID1 array that is mounted as "/" but I replaced the device and the 
problem is still happening.


I had been able to fix it by booting to SystemRescue and running an 
fsck on the device but it didn't work this time. The device checks out 
OK (even when using fsck -/dev/mdx -f) but I still can't list the 
root. "ls -l /" just hangs, as do any attempts to see the root 
directory in a graphical file manager. In dolphin this means there is 
nothing in the folders - and since that is the default starting point 
I have to manually enter a folder name (e.g. /home/me) in the location 
bar to be able to see anything - but even then the folders panel 
remains empty.


Even running commands like df -h hang because they can't access the 
root folder. However the system is otherwise running normally.


Strangely, in the past simply booting to a rescue shell then exiting 
would also work. I'd usually try to do an fsck on the raid device but 
that would always fail because it was mounted.


The only thing I noticed that was unusual was I rebooted after 
installing the latest Trixie updates this morning. That took about 10 
minutes to shut down - 6 of which were spent waiting for a drkonqi 
process to finish. There was also a systemd message really late in the 
shutdown about /dev/md0 but that's not the root device.


I'm used to Linux taking its time to shutdown lately so I don't think 
this was related. The systemd shutdown just seems to be easily delayed.


Any ideas on how I can restore my ability to see the root directory?

OK, got it working again. I used tune2fs to do an fsck on every boot. 
This being an NVME device, it's barely noticeable.

Re: chrony date months off

[gene heskett]

On 1/31/24 07:13, Max Nikulin wrote:

On 31/01/2024 17:54, to...@tuxteam.de wrote:

I think you want "maxstep". It's in the man page chrony.conf(5).

But if the time is "months off" perhaps you've got another problem
to fix first?
Well, I do have other probs with that machine, mostly with the physicsl 
config of the BTT Octopus Pro 3dprinter control card its running, but 
that is not os related, it just a detail I have fixed on all the other 
machines.


I think, the problem is no RTC on some *pi board, certainly chrony out 
of box setup is not ready to such environment and its solution is not 
maxstep.


Gene, are you going to complain again that some package has no man pages?


Mope.  Thanks Max

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: Can't list root directory

[Gary Dale]

On 2024-01-29 12:55, Hans wrote:

Hi Gary,

before loosing any data, I suggest, to boot from a liuvefile linux. Please use
a modern livefile like Knoppix or Kali-Linux.

If it is not a BIOS problem, you should see the device again and are able to
mount it. If /root is on a seperated partition, you can do some filesystem
checks, like e2fsck or else.

Ans: Most important, with a livefile system you can mount an external harddrive
and backup all files. Thus , even when the /dev/nvme*** is died or partly
broken, you can maybe restore /root on another partition.

Second: Please check ACL, although I do not believe the reason for these, it
is worth to look at this. Maybe you or someone else has chenged it accidently.

Third idea: Is the harddrive full? In the past I has the problem, not to be
able to do anything. The reason: My harddrive was completely full (some
temporary file was the reason). Deleting this big file was the trick.

Just some ideas, maybe it could help.

Good luck!

Best

Hans


There is no problem seeing the root folder when I boot from a live distro.

fsck never finds any significant issue.

An ACL issue would be permanent. This comes and goes.

I actually doubled the size of the root device when I put in the new 
NVME drive. When I set up the RAID array, I'd bought a 500G second drive 
to mirror the 256G original drive. When I replaced the 256G drive, I was 
able to expand the array to 500G (less a small amount for the EFI 
partition). The partition has lots of free space.


As I said, running an fsck seems to fix the issue temporarily. I now run 
an fsck on every boot.

Re: Can't list root directory

[The Wanderer]

On 2024-01-29 at 11:42, Gary Dale wrote:

> I'm running Debian/Trixie on an AMD64 workstation. I've lost the
> ability to see the root directory even when I am logged in as root
> (su -).
> 
> This has been happening intermittently for several months. I
> initially thought it might be related to failing NVME drive that was
> part of a RAID1 array that is mounted as "/" but I replaced the
> device and the problem is still happening.
> 
> I had been able to fix it by booting to SystemRescue and running an
> fsck on the device but it didn't work this time. The device checks
> out OK (even when using fsck -/dev/mdx -f) but I still can't list the
> root. "ls -l /" just hangs, as do any attempts to see the root
> directory in a graphical file manager. In dolphin this means there is
> nothing in the folders - and since that is the default starting point
> I have to manually enter a folder name (e.g. /home/me) in the
> location bar to be able to see anything - but even then the folders
> panel remains empty.
> 
> Even running commands like df -h hang because they can't access the
> root folder. However the system is otherwise running normally.

I'm not sure it'll help lead to anything, but out of curiosity and/or as
a possible diagnostic: when the problem is manifesting, what happens if
you run 'stat /'? Does it report data (similar to what you'd get from
'stat' on another directory), or does it hang, or give errors, or...?

My thought is that this will give information about the filesystem
object that is the root directory, without trying to also access
information about the *contents* of that directory. If the one succeeds
where the other fails, that might help narrow down where the actual
issue is.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: chrony date months off

[John Hasler]

Max Nikulin wrote:
> I think, the problem is no RTC on some *pi board, certainly chrony out of
> box setup is not ready to such environment and its solution is not
> maxstep.

That's what makestep (initstepslew now being deprecated) is for.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: Automatically installing GRUB on multiple drives

[Andy Smith]

Hi,

On Tue, Jan 30, 2024 at 09:50:23PM +0100, hw wrote:
> On Mon, 2024-01-29 at 23:53 +, Andy Smith wrote:
> > I think you should read it again until you find the part where it
> > clearly states what the problem is with using MD RAID for this. If
> > you still can't find that part, there is likely to be a problem I
> > can't assist with.
> 
> That there may be a problem doesn't automatically mean that you need a
> bunch of scripts.

This is getting quite tedious.

Multiple people have said that there is a concern that UEFI firmware
might write to an ESP, which would invalidate the use of software
RAID for the ESP.

Multiple people have suggested instead syncing ESP partitions in
userland. If you're going to do that then you'll need a script to do
it.

I don't understand what you find so difficult to grasp about this.
If it's that you have some other proposal for solving this, it would
be helpful for you to say so, instead of just repeating "why do you
need scripts, you don't need scripts", because if you just repeat
that, all I can do is repeat what I've already said until I become
bored and stop.

If your suggested solution is "use hardware RAID", no need to repeat
that one though: I see you said it in a few other messages, and that
suggestions has been received. Assume the conversation continues
amongst people who don't like that suggestion.

Otherwise, I don't think anyone knows what you have spent several
messages trying to say. All we got was, "you don't need scripts".

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: chrony date months off

[gene heskett]

On 1/31/24 08:53, John Hasler wrote:

Gene writes:

How do I setup /etc/chrony/chrony.conf so it slams the system clock to
the current time on the first cycle as its rebooting?


initstepslew

man chrony.conf


deprecated in favor of makestep, and did not work, John.

Thanks, John

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: chrony date months off

[Greg Wooledge]

On Wed, Jan 31, 2024 at 10:25:40AM -0500, gene heskett wrote:
> On 1/31/24 08:53, John Hasler wrote:
> > Gene writes:
> > > How do I setup /etc/chrony/chrony.conf so it slams the system clock to
> > > the current time on the first cycle as its rebooting?
> > 
> > initstepslew
> > 
> > man chrony.conf
> 
> deprecated in favor of makestep, and did not work, John.

*sigh*

How many times do we have to say it?  When something goes wrong, don't
simply say "it didn't work".  Give the *details*.

What changes did you make to files?  What do the files look like now?

What commands did you run?

What output did you get?

What output did you *expect* to get?

What other relevant details can you supply?  (The identities and
configurations of the NTP servers that chrony is expected to use, for
example.)

Re: Can't list root directory

[Max Nikulin]

On 29/01/2024 23:42, Gary Dale wrote:

"ls -l /" just hangs


It may dereference symlinks, call stat, etc. to colorize output. May it 
happen that you have automount points or something related to network 
mounts?


Does "echo /*" hangs?

Even bash prompt may do some funny stuff. I would try it from "dash".

Can you install strace? E.g. copy files while booted from a live media.

Re: chrony date months off

[gene heskett]

On 1/31/24 10:44, Greg Wooledge wrote:

On Wed, Jan 31, 2024 at 10:25:40AM -0500, gene heskett wrote:

On 1/31/24 08:53, John Hasler wrote:

Gene writes:

How do I setup /etc/chrony/chrony.conf so it slams the system clock to
the current time on the first cycle as its rebooting?


initstepslew

man chrony.conf


deprecated in favor of makestep, and did not work, John.


*sigh*

How many times do we have to say it?  When something goes wrong, don't
simply say "it didn't work".  Give the *details*.

What changes did you make to files?  What do the files look like now?

gene@bpi51e5p:/etc/chrony$ cat chrony.conf
# Welcome to the chrony configuration file. See chrony.conf(5) for more
# information about usable directives.

# Include configuration files found in /etc/chrony/conf.d.
confdir /etc/chrony/conf.d

# This will use (up to):
# - 4 sources from ntp.ubuntu.com which some are ipv6 enabled
# - 2 sources from 2.ubuntu.pool.ntp.org which is ipv6 enabled as well
# - 1 source from [01].ubuntu.pool.ntp.org each (ipv4 only atm)
# This means by default, up to 6 dual-stack and up to 2 additional IPv4-only
# sources will be used.
# At the same time it retains some protection against one of the entries 
being

# down (compare to just using one of the lines). See (LP: #1754358) for the
# discussion.
#
# About using servers from the NTP Pool Project in general see (LP: 
#104525).

# Approved by Ubuntu Technical Board on 2011-02-08.
# See http://www.pool.ntp.org/join.html for more information.
#pool ntp.ubuntu.comiburst maxsources 4
#pool 0.ubuntu.pool.ntp.org iburst maxsources 1
#pool 1.ubuntu.pool.ntp.org iburst maxsources 1
#pool 2.ubuntu.pool.ntp.org iburst maxsources 2

# Use time sources from DHCP.
sourcedir /run/chrony-dhcp
sourcedir /etc/chrony/sources.d

# This directive specify the location of the file containing ID/key 
pairs for

# NTP authentication.
keyfile /etc/chrony/chrony.keys

# This directive specify the file into which chronyd will store the rate
# information.
driftfile /var/lib/chrony/chrony.drift

# Save NTS keys and cookies.
ntsdumpdir /var/lib/chrony

# Uncomment the following line to turn logging on.
#log tracking measurements statistics

# Log files location.
logdir /var/log/chrony

# Stop bad estimates upsetting machine clock.
maxupdateskew 10.0
initstepslew 30 192.168.71.3
# This directive enables kernel synchronisation (every 11 minutes) of the
# real-time clock. Note that it can’t be used along with the 'rtcfile' 
directive.

rtcsync

# Step the system clock instead of slewing it if the adjustment is 
larger than

# one second, but only in the first three clock updates.
makestep 1 3000

# Get TAI-UTC offset and leap seconds from the system tz database.
# This directive must be commented out when using time sources serving
# leap-smeared time.
leapsectz right/UTC
gene@bpi51e5p:/etc/chrony$

Now, the file in /etc/chrony/sources.d:
gene@bpi51e5p:/etc/chrony/sources.d$ cat local-ntp-server.sources
server 192.168.71.3 iburst
gene@bpi51e5p:/etc/chrony/sources.d$



What commands did you run?


6 of one half a dozen of the other
gene@bpi51e5p:/etc/init.d$ sudo ./chrony status
[sudo] password for gene:
× chrony.service - chrony, an NTP client/server
 Loaded: loaded (/lib/systemd/system/chrony.service; enabled; 
vendor preset: enabled)
 Active: failed (Result: protocol) since Sat 2023-12-30 03:15:44 
EST; 2h 12min ago

   Docs: man:chronyd(8)
 man:chronyc(1)
 man:chrony.conf(5)
Process: 1908 ExecStart=/usr/lib/systemd/scripts/chronyd-starter.sh 
$DAEMON_OPTS (code=exited, status=0/SUCCESS)

CPU: 158ms

Dec 30 03:15:31 bpi51e5p chronyd[1936]: chronyd version 4.2 starting 
(+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGN…6 -DEBUG)
Dec 30 03:15:31 bpi51e5p chronyd[1936]: Frequency -20.055 +/- 0.010 ppm 
read from /var/lib/chrony/chrony.drift
Dec 30 03:15:32 bpi51e5p chronyd[1936]: Using right/UTC timezone to 
obtain leap second data

Dec 30 03:15:32 bpi51e5p chronyd[1936]: Loaded seccomp filter (level 1)
Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3
Dec 30 03:15:42 bpi51e5p chronyd[1936]: No suitable source for initstepslew
Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3
Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: New main PID 1936 
does not exist or is a zombie.
Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: Failed with result 
'protocol'.
Dec 30 03:15:44 bpi51e5p systemd[1]: Failed to start chrony, an NTP 
client/server.

Hint: Some lines were ellipsized, use -l to show in full.
gene@bpi51e5p:/etc/init.d$

or

gene@bpi51e5p:/etc/init.d$ sudo systemctl status chrony.service
× chrony.service - chrony, an NTP client/server
 Loaded: loaded (/lib/systemd/system/chrony.service; enabled; 
vendor preset: enabled)
 Active: failed (Result: protocol) since Sat 2023-12-30 03:15:44 
EST; 2h 13min ago

   Docs: man:chronyd(8)
 man:chronyc(1)

Re: Debian/Xen on ARM: How to identify source of an unhandled SMC call during boot?

[Andrew M.A. Cater]

On Wed, Jan 31, 2024 at 08:02:47AM +0100, Paul Leiber wrote:
> Am 25.01.2024 um 22:28 schrieb Paul Leiber:
> > 
> > Paul
> > 
> > [1]
> > https://lists.xenproject.org/archives/html/xen-devel/2023-10/msg00796.html
> > [2] https://developer.arm.com/documentation/den0098/latest/
> > [3] 
> > https://documentation-service.arm.com/static/628b755ce3c4322a76af56de?token=
> > 
> 
> Hm, no reply so far. Is this maybe the wrong list? Should I post this rather
> somewhere else?
> 
> Paul
>

debian-arm / OFTC IRC #debian-arm or #debian-raspberrypi

Xen in Debian is team maintained, I think, but many people have moved
away from Xen in favour of other virtualisation/paravirtualisation
solutions and containers.

All the very best, as ever,

Andy
(amaca...@debian.org) 

Re: chrony date months off

[Greg Wooledge]

On Wed, Jan 31, 2024 at 12:56:37PM -0500, gene heskett wrote:
[...]
> # Stop bad estimates upsetting machine clock.
> maxupdateskew 10.0
> initstepslew 30 192.168.71.3
> # This directive enables kernel synchronisation (every 11 minutes) of the
> # real-time clock. Note that it can’t be used along with the 'rtcfile'
> directive.
> rtcsync
> 
> # Step the system clock instead of slewing it if the adjustment is larger
> than
> # one second, but only in the first three clock updates.
> makestep 1 3000

I've never used chrony, so all I know about it is what I've gleaned
from skimming the chrony.conf page, from Google search results, and
from things that people have said here.

With that in mind, I don't know what happens if you've got both
initstepslew *and* makestep in the same conf file.  I would imagine
you only want one of them.

> Dec 30 03:15:32 bpi51e5p chronyd[1936]: Using right/UTC timezone to obtain
> leap second data
> Dec 30 03:15:32 bpi51e5p chronyd[1936]: Loaded seccomp filter (level 1)
> Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3
> Dec 30 03:15:42 bpi51e5p chronyd[1936]: No suitable source for initstepslew
> Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3

That IP address clearly came from your initstepslew line.  Is there an
NTP service running on that host?  If so, is it synchronized?  And does
it permit client requests (from bpi51e5p)?

> Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: New main PID 1936 does
> not exist or is a zombie.
> Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: Failed with result
> 'protocol'.
> Dec 30 03:15:44 bpi51e5p systemd[1]: Failed to start chrony, an NTP
> client/server.

This appears to be important.  It's failing to start, which means it's
not setting the clock, or doing anything else.  You'll need to figure
out why it's not starting.  Perhaps it's *just* the fact that it can't
contact an NTP service at 192.168.71.3.  Or maybe there's more to the
story.  I don't know.

Re: chrony date months off

[Darac Marjal]

On 31/01/2024 12:12, Max Nikulin wrote:

On 31/01/2024 17:54, to...@tuxteam.de wrote:

I think you want "maxstep". It's in the man page chrony.conf(5).

But if the time is "months off" perhaps you've got another problem
to fix first?


I think, the problem is no RTC on some *pi board, certainly chrony out 
of box setup is not ready to such environment and its solution is not 
maxstep.


Gene, are you going to complain again that some package has no man pages?

For Raspberry Pi's, Ubuntu offer a script similar to the following 
https://github.com/Jolicloud/initramfs-tools/blob/master/scripts/local-premount/fixrtc 
(I couldn't find an equivalent to https://sources.debian.net for Ubuntu, 
but the script is simple enough that I doubt if it's very different).


The script works like this: if the root device is specified on the 
kernel command line AND the word "fixrtc" is  specified, then get the 
time that the root file system was last mounted. The script then uses 
"date" to set the clock to that date stamp.


I assume that the idea is that, rather than having the clock start at 
1970, it's better to start it at, say, yesterday. You've still got quite 
a lot of slewing to do if you connect to NTP, but at least there's a 
chance that you can verify certificates etc.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: AW: AW: su su- sudo dont work

[Andrew M.A. Cater]

On Wed, Jan 31, 2024 at 01:58:41PM +, Schwibinger Michael wrote:
> Good afternoon
> I think
> maybe Im sure
> it is because of rescue mode.
> 
Hi Sophie,

Once again: we need to you to show us what commands you run.

We need to see error messages.

if you cannot run sudo or su, we need you to run the id command
as previously suggested.

We have literally nothing of use from you to help any of us problem
solve. This is throwing good effort away in persuading you to help us.

Also - please address requests first to the list and not to individuals -
it makes it a lot easier to follow on the list.

> Normal booting did not have this problem.
> 
> Anybody familiar with panic?
> 
> Regards
> Thank You
> Sophie
> 
Andy
> 
> 
> Von: Andrew M.A. Cater 
> Gesendet: Donnerstag, 25. Januar 2024 18:40
> An: debian-user@lists.debian.org 
> Betreff: Re: AW: su su- sudo dont work
> 
> On Thu, Jan 25, 2024 at 03:53:10PM +, Schwibinger Michael wrote:
> > Good afternoon
> > Why do I have to open a group?
> >
> 
> This is to *tell* us information about why you're having problems with su
> and sudo
> 
> Running the
> 
> id
> 
> command should give you information like
> 
> uid=1000(amacater) gid=1000(amacater) groups=1000(amacater),27(sudo)
> 
> which shows you that my user - amacater - is the first user on the
> machine (because Debian starts user id numbers at 1000 for ordinary
> users) and that I'm a member of group sudo - so can use sudo instead of su.
> 
> /etc/sudoers will show you what privileges the sudo user has.
> Here are the last lines of the file on my machine (which has not been
> modified from Debian defaults)
> 
> # User privilege specification
> rootALL=(ALL:ALL) ALL
> 
> # Allow members of group sudo to execute any command
> %sudo   ALL=(ALL:ALL) ALL
> 
> # See sudoers(5) for more information on "@include" directives:
> 
> @includedir /etc/sudoers.d
> (END)
> 
> If you are _not_ a user of group sudo for whatever reason - and want to
> use sudo - then you will need root privileges and the root password
> (once) to add your user name to the group.
> 
> For example: adduser sophie sudo
> 
> I hope this helps
> 
> > 2 years ago
> > sudo was no problem.
> >
> 
> As yet, we have *no idea* what you have done in the last two years to
> break your Debian system - or even to know which kernel you boot or
> how you "rescue" your system when you log onto it every day.
> 
> Please give us information in order that the readers on this list can
> use their knowledge to help you.
> 
> With every good wish, as ever,
> 
> Andy
> (amaca...@debian.org)
> > Regards
> >
> > Sophie
> >
> > Thank You
> > 
> > Von: Timothy M Butterworth 
> > Gesendet: Montag, 22. Januar 2024 00:07
> > An: Schwibinger Michael 
> > Cc: Greg Wooledge ; debian-user@lists.debian.org 
> > 
> > Betreff: Re: su su- sudo dont work
> >
> >
> >
> > On Sun, Jan 21, 2024 at 4:07 PM Schwibinger Michael 
> > mailto:h...@hotmail.com>> wrote:
> > Thank You
> > Example
> > I say
> >
> > sudo apt-get install firefox
> > Reaction LINUX
> > This is not allowed we send a message to the admin.
> >
> > This error message means that your account is not in the sudo group.
> >
> > Run the command "groups" and look for the group sudo.
> > groups
> >
> > Here is the command to add a user account to the sudo group. You will need 
> > to run it as root.
> > usermod -a -G sudo 
> >
> > I do open root terminal
> > there its working.
> > Regards
> > Sophie
> >
> > 
> > Von: Greg Wooledge mailto:g...@wooledge.org>>
> > Gesendet: Samstag, 20. Januar 2024 14:14
> > An: debian-user@lists.debian.org 
> > mailto:debian-user@lists.debian.org>>
> > Betreff: Re: su su- sudo dont work
> >
> > On Sat, Jan 20, 2024 at 01:26:06PM +, Schwibinger Michael wrote:
> > > Good afternoon.
> > > Root terminal is fine.
> > > What do I do wrong?
> > > What did I destroy?
> > >
> > > PC does have only one user=admin.
> > >
> > > Regards Sophie
> > > Is it the rescue mode?
> >
> > Explain, please.
> >
> > Your Subject: header says "su su- sudo dont work".  What does this MEAN?
> >
> > Please show us your attempts to USE each of these commands, and the
> > results that you got.  This means, run the commands in a terminal
> > window, and then PASTE the contents of that terminal window into the
> > body of your next email.  Show us the shell prompt, the command as you
> > typed it, and the full output.
> >
> > In other words, show us WHAT IS WRONG, or at least what appears wrong.
> >
> > In addition, please give basic background information -- what version
> > of Debian you are running, what desktop environment if any, how you
> > logged in (*especially* if it isn't just a "standard graphical login
> > for your desktop environment"), and anything else you can think of
> > that might be relevant.
> >
> > How does "rescue mode" factor into the problem?
> >
> > When yo

Re: Debian/Xen on ARM: How to identify source of an unhandled SMC call during boot?

[hw]

On Wed, 2024-01-31 at 08:02 +0100, Paul Leiber wrote:
> Am 25.01.2024 um 22:28 schrieb Paul Leiber:
> > Dear Debian user list members,
> > 
> > I am trying to run network related stuff (Samba, Zabbix) on a Raspberry 
> > Pi 4B in a virtualized environment using Debian Bookworm and Xen. I am 
> > running into reproducible complete system crashes/reboots due to a Xen 
> > watchdog triggering under certain, seemingly strange conditions (the 

Raspberry Pis have a watchdog?

Maybe disable the watchdog and see what happens?

> > number of VLANs involved seems to play a role, running tcpdump on 
> > certain interfaces prevents this issue, ...). If you are interested in 
> > the long version, you can find it here [1].
> > 
> > Some people on xen-devel pointed out to me two unhandled SMC calls in 
> > the boot logs which could be the root of the problem. I am now trying to 
> > find out where these calls come from to get closer to the root cause. 
> > The suspected calls are the following ones:
> > 
> > (XEN) d0v0 Unhandled SMC/HVC: 0x8450
> > (XEN) d0v0 Unhandled SMC/HVC: 0x8600ff01
> > 
> > These calls happen during the Dom0 boot process, so it's something from 
> > inside Linux and nothing Xen related, I've been told. The current 
> > working hypothesis is that the calls are trying to find some module not 
> > emulated by Xen and are therefore failing, leading to Linux waiting for 
> > the reply, and subsequently to the Xen watchdog triggering and rebooting.
> > 
> >  From what I could find out in ARM documentation, the unhandled SMC 
> > calls probably have the following purpose:
> > 
> > 0x8450 = TRNG_VERSION, returns the implemented TRNG (True Random 
> > Number Generator) ABI version [2]
> > 0x8600ff01 = Call UID Query for Vendor Specific Hypervisor Service, 
> > Returns a unique identifier of the service provider [3]
> > 
> > The more likely cause is the second call to the address 0x8600ff01.
> > 
> > Now I simply have no idea how to find out where in the Linux boot 
> > process these calls are made. I tried poking into the Linux sources a 
> > bit, and I couldn't find an exact match for these call addresses, so I 
> > assume these addresses are assembled from different parts. There are 
> > some matches for "0x8600" and for "ff01", but I couldn't identify if 
> > these matches are relevant.
> > 
> > I tried to find out if strace could help, but from what I understand, 
> > this is related to commands coming from userspace, so I am not sure that 
> > strace helps during the boot process.
> > 
> > I'd appreciate it if somebody more knowledgeable would point me in the 
> > right direction. If more information is needed, I can provide it.

I would search for the message 'Unhandled SMC/HVC' itself, or even for
'Unhandled', not for the address.  The address is probably determined
at runtime and not hardcoded.

Do you get better results with qemu/kvm?  Xen is more like 'hmm' than
anything else.

SOLVED:Re: chrony date months off

[gene heskett]

On 1/31/24 13:19, Greg Wooledge wrote:

On Wed, Jan 31, 2024 at 12:56:37PM -0500, gene heskett wrote:
[...]

# Stop bad estimates upsetting machine clock.
maxupdateskew 10.0
initstepslew 30 192.168.71.3
# This directive enables kernel synchronisation (every 11 minutes) of the
# real-time clock. Note that it can’t be used along with the 'rtcfile'
directive.
rtcsync


I'll comment that line

# Step the system clock instead of slewing it if the adjustment is larger
than
# one second, but only in the first three clock updates.
makestep 1 3000
I had tried 30, and it did it about that many time ack the tcpdump log 
I'm tracking.  And I'll put the 300 back in, that ack the tcpdump 
monitor seemed to effective. but I've not found in the docs, anything 
that will modify how far the step will change it, The first arg is one 
second.


chrony seems to  be the fave method for the arm64's but I have had 
better luck using ntpsec without the security on all other wintel 
machines.  Its ntpsec I'm using on this machine to be a stratum 2 server 
for the rest of my local net.  So that's what all the other local 
machines see.  timedatectl bombs when asked to set-time, regardless of 
how many space separated arguments is says too many arguments. Aha! the 
time argument needs single quotes around it!  The help screen is wrong 
but the man page says " ".  So I have it now set for about 4 hours ago.
Now about 5 seconds off, but its not querying my server.  More man page 
perusal. I am getting the impression that timedatctl ultimately uses he 
first time service it can find, and while I have the clock sey pretty 
close, it nat offer ntp until there is an available ntp client, and I 
used apt to purge both chrony and ntpsec. So I;ll reinstall ntpsec. Done


Then I went clear around the mulberry tree and copied (because my sshnet 
mounts of all these machine is as a user) the 
/sshnet/go704/etc/ntpsec/ntp.conf to my home dir on that box, then fired 
up a user mc and copied that file from /sshnet/go704/home/gene to 
/sshnet/bpi51/home/gene.
went to a different workspace, fired up a sudo mc, copied that file to 
that machines /etc/ntpsec dir, then fixed the perms back to 0600.


Then restarted ntpsec by stopping it, then starting it again so it would 
read the new file. Then:


gene@bpi51e5p:~$ timedatectl status
   Local time: Wed 2024-01-31 15:40:13 EST
   Universal time: Wed 2024-01-31 20:40:13 UTC
 RTC time: Wed 2024-01-31 20:40:13
Time zone: America/New_York (EST, -0500)
System clock synchronized: yes
  NTP service: n/a
  RTC in local TZ: no

And my tcpdump trace here?:
15:51:01.235371 IP bpi51e5p.coyote.den.ntp > coyote.coyote.den.ntp: 
NTPv4, Client, length 48
15:51:01.235523 IP coyote.coyote.den.ntp > bpi51e5p.coyote.den.ntp: 
NTPv4, Server, length 48
15:52:06.236633 IP bpi51e5p.coyote.den.ntp > coyote.coyote.den.ntp: 
NTPv4, Client, length 48
15:52:06.236701 IP coyote.coyote.den.ntp > bpi51e5p.coyote.den.ntp: 
NTPv4, Server, length 48


IOW, its working.  And I found another off by about an hour, so I copied 
that same file it it, problem solved.


Now, I still have more cats to skin but solving those two problems will 
help.  Now I can get back to the real problem. Lack of docs to make a 
TMC-2209, a very common motor driver in the stepstick category, work in 
the uart interface mode in a BTT octopus Pro controller cards driver 
sockets 2, 3 & 4.  Add about 12 jumpers and put them back in 
step/dir/enable mode is the next test. That's going to take some coffee 
I haven't made yet today.


Thanks for the nudge to make me think, Greg, take care & stay well.

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: Can't list root directory

[hw]

On Wed, 2024-01-31 at 09:27 -0500, Gary Dale wrote:
> On 2024-01-30 15:54, hw wrote:
> > On Mon, 2024-01-29 at 11:42 -0500, Gary Dale wrote:
> > > I'm running Debian/Trixie on an AMD64 workstation. I've lost the ability
> > > to see the root directory even when I am logged in as root (su -).
> > > 
> > > This has been happening intermittently for several months. I initially
> > > thought it might be related to failing NVME drive that was part of a
> > > RAID1 array that is mounted as "/" but I replaced the device and the
> > > problem is still happening.
> > > [...]
> > What happens when you put the device you replaced back?
> > 
> How could putting a known-failing device back in help? The problem 
> existed before I replaced it and continues to exist after the replacement.

It sounded like you were able to list the root directory (at least
sometimes) before you did the replacement.  Manually failing the
device (perhaps after adding it back first) could make a difference.

I've seen such indefinite hangs only when an NFS share has become
unreachable after it had been mounted.  You could use clonezilla to
make a copy and then perhaps convert the file system to btrfs.

Do you still have the problem when you remove one of the NVME storage
things?  Perhaps you have the equivivalent of a bad SATA cable or the
mainboard doesn't like it when you access two of those at the same
time, or something like that.  Even simple network cables can behave
very strangely, and NVME may be a bit more complicated than that.

Running fsck on every boot to work around an issue like this is
certainly a bad idea.  Doesn't fsck report anything?  If it really
makes a difference in itself rather than creating some side effect
that leads to the root directory being readable, it should report
something.  Perhaps you need to increase its verbosity.

If there's no report then it would look like a side effect and raise
the question what side effect it might be.  Does fsck run before the
RAID has been brought up or after?  Is the RAID up when booting is
completed?  What does mdadm say about the device(s)?  Can you still
list the root directory when you manually fail either drive?  What
exactly are the circumstances under which you can and not list the
root directory?

You need to do some investigating and ask questions like those ...

Re: chrony date months off

[hw]

On Wed, 2024-01-31 at 12:56 -0500, gene heskett wrote:
> [...]
> Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3
> Dec 30 03:15:42 bpi51e5p chronyd[1936]: No suitable source for initstepslew
> Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3
> Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: New main PID 1936 
> does not exist or is a zombie.
> Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: Failed with result 
> 'protocol'.

Perhaps uncomment one/some of the pool address(es) in its config to
allow chrony to find a suitable server.

Re: chrony date months off

[Steve McIntyre]

Darac Marjal  wrote:
>
>The script works like this: if the root device is specified on the 
>kernel command line AND the word "fixrtc" is  specified, then get the 
>time that the root file system was last mounted. The script then uses 
>"date" to set the clock to that date stamp.
>
>I assume that the idea is that, rather than having the clock start at 
>1970, it's better to start it at, say, yesterday. You've still got quite 
>a lot of slewing to do if you connect to NTP, but at least there's a 
>chance that you can verify certificates etc.

I also wrote fake-hwclock (packaged in Debian) for this kind of reason.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Re: Automatically installing GRUB on multiple drives

[hw]

On Wed, 2024-01-31 at 15:16 +, Andy Smith wrote:
> Hi,
> 
> On Tue, Jan 30, 2024 at 09:50:23PM +0100, hw wrote:
> > On Mon, 2024-01-29 at 23:53 +, Andy Smith wrote:
> > > I think you should read it again until you find the part where it
> > > clearly states what the problem is with using MD RAID for this. If
> > > you still can't find that part, there is likely to be a problem I
> > > can't assist with.
> > 
> > That there may be a problem doesn't automatically mean that you need a
> > bunch of scripts.
> 
> This is getting quite tedious.
> 
> Multiple people have said that there is a concern that UEFI firmware
> might write to an ESP, which would invalidate the use of software
> RAID for the ESP.
> 
> Multiple people have suggested instead syncing ESP partitions in
> userland. If you're going to do that then you'll need a script to do
> it.
> 
> I don't understand what you find so difficult to grasp about this.

You kept only saying 'read the link'.  Well, read the link!  It points
out 4 choices and none of them says 'you need a bunch of scripts'.

> If it's that you have some other proposal for solving this, it would
> be helpful for you to say so

I already said my solution is using hardware raid or fixing the
problem in all the UEFI BIOSs.

I'd also say that the BIOS must never write to the storage, be it to
an UEFI partition or anywhere else.  But that's a different topic.

> [...]
> If your suggested solution is "use hardware RAID", no need to repeat
> that one though: I see you said it in a few other messages, and that
> suggestions has been received. Assume the conversation continues
> amongst people who don't like that suggestion.

Well, too late, I already said it again since you asked.  Do you have
a better solution?  It's ok not to like this solution, but do you have
a better one?

> Otherwise, I don't think anyone knows what you have spent several
> messages trying to say. All we got was, "you don't need scripts".

What do you expect when you keep repeating 'read the link'.

Re: Debian/Xen on ARM: How to identify source of an unhandled SMC call during boot?

[Paul Leiber]

Am 31.01.2024 um 19:07 schrieb Andrew M.A. Cater:

On Wed, Jan 31, 2024 at 08:02:47AM +0100, Paul Leiber wrote:

Am 25.01.2024 um 22:28 schrieb Paul Leiber:


Paul

[1]
https://lists.xenproject.org/archives/html/xen-devel/2023-10/msg00796.html
[2] https://developer.arm.com/documentation/den0098/latest/
[3] https://documentation-service.arm.com/static/628b755ce3c4322a76af56de?token=



Hm, no reply so far. Is this maybe the wrong list? Should I post this rather
somewhere else?

Paul



debian-arm / OFTC IRC #debian-arm or #debian-raspberrypi

Xen in Debian is team maintained, I think, but many people have moved
away from Xen in favour of other virtualisation/paravirtualisation
solutions and containers.

All the very best, as ever,

Andy
(amaca...@debian.org)


Thank you for the reply, Andy. I'll try my luck there.

Paul

Re: Debian/Xen on ARM: How to identify source of an unhandled SMC call during boot?

[Tixy]

On Wed, 2024-01-31 at 21:59 +0100, hw wrote:
> On Wed, 2024-01-31 at 08:02 +0100, Paul Leiber wrote:
> > Am 25.01.2024 um 22:28 schrieb Paul Leiber:
> > [...]
> > > Some people on xen-devel pointed out to me two unhandled SMC calls in 
> > > the boot logs which could be the root of the problem. I am now trying to 
> > > find out where these calls come from to get closer to the root cause. 
> > > The suspected calls are the following ones:
> > > 
> > > (XEN) d0v0 Unhandled SMC/HVC: 0x8450
> > > (XEN) d0v0 Unhandled SMC/HVC: 0x8600ff01
> > > 
> > > These calls happen during the Dom0 boot process, so it's something from 
> > > inside Linux and nothing Xen related, I've been told. The current 
> > > working hypothesis is that the calls are trying to find some module not 
> > > emulated by Xen and are therefore failing, leading to Linux waiting for 
> > > the reply, and subsequently to the Xen watchdog triggering and rebooting.
> > > 
> > >  From what I could find out in ARM documentation, the unhandled SMC 
> > > calls probably have the following purpose:
> > > 
> > > 0x8450 = TRNG_VERSION, returns the implemented TRNG (True Random 
> > > Number Generator) ABI version [2]
> > > 0x8600ff01 = Call UID Query for Vendor Specific Hypervisor Service, 
> > > Returns a unique identifier of the service provider [3]
> > > 
> > > The more likely cause is the second call to the address 0x8600ff01.
> > > 
> > > Now I simply have no idea how to find out where in the Linux boot 
> > > process these calls are made. I tried poking into the Linux sources a 
> > > bit, and I couldn't find an exact match for these call addresses, so I 
> > > assume these addresses are assembled from different parts. There are 
> > > some matches for "0x8600" and for "ff01", but I couldn't identify if 
> > > these matches are relevant.
> > > 
> > > I tried to find out if strace could help, but from what I understand, 
> > > this is related to commands coming from userspace, so I am not sure that 
> > > strace helps during the boot process.
> > > 
> > > I'd appreciate it if somebody more knowledgeable would point me in the 
> > > right direction. If more information is needed, I can provide it.
> 
> I would search for the message 'Unhandled SMC/HVC' itself, or even for
> 'Unhandled', not for the address.  The address is probably determined
> at runtime and not hardcoded.

I sure those hex values aren't 'addresses' but the ID's for the secure
monitor calls Paul already identified.

Looking at the Linux sources I found the header for constructing these
monitor calls: include/linux/arm-smccc.h

So it might be worth looking at the files that include that. There are
various drivers for firmware, and a watchdog driver amongst other
things... drivers/watchdog/arm_smc_wdt.c

-- 
Tixy

Re: Automatically installing GRUB on multiple drives

[hw]

On Tue, 2024-01-30 at 21:35 +0100, Nicolas George wrote:
> hw (12024-01-30):
> > Yes, and how much effort and how reliable is doing that?
> 
> Very little effort and probably more reliable than hardware RAID with
> closed-source hardware.

Well, I doubt it.  After all you need to copy a whole partition and
must make sure that it doesn't fail through distribution upgrades and
all kinds of possible changes and even when someone shuts down or
reboots the computer or pulls the plug while the copying is still in
progress.  You also must make sure that the boot manager is installed
on multiple disks.

And when you're going to do it?  When shutting the machine down?
Might not happen and when it does happen, maybe you don't want to wait
on it.

When rebooting it?  Perhaps you don't want to overwrite the copy at
that time, or perhaps it's too late then because there were software
updates before you rebooted and one of the disks failed when
rebooting.

Do you suggest to install backup batteries or capacitors to keep the
machine running until the copying process has completed when the power
goes out?

Or do you want to do it all manually at a time convenient for you?
What if you forgot to do it?


I'm not so silly that you could convince me that you can do it more
reliably than the hardware RAID does it whith a bunch of scripts you
put together yourself, especially not by implying that the hardware
raid which has been tested in many datacenters with who knows how many
hundreds of thousands of machines over many years uses closed source
software which has been maintained and therefore must be unreliable.

The lowest listed MTBF of hardware RAID is over 26 hours
(i. e. about 30 years) on [1].  Can you show that you can do it more
reliably with your bunch of scripts?


[1]: 
https://www.intel.com/content/www/us/en/support/articles/07641/server-products/sasraid.html

Probelms with apparmor

[Steven Truppe]

    Hey,


i've the follwoing trouble: when i try to run certain apps it takes
forever tostart. i can get rid of the troble by typing $service apparmor
reload but that's not a partmanent soutoin.

can someone pleae help me out here ?


best regards!

Re: Automatically installing GRUB on multiple drives

[Nicolas George]

hw (12024-01-31):
> Well, I doubt it.

Well, doubt it all you want. In the meantime, we will continue to use
it.

Did not read the rest, not interested in red herring nightmare
scenarios.

-- 
  Nicolas George

Re: Automatically installing GRUB on multiple drives

[hw]

On Wed, 2024-01-31 at 06:33 +0100, to...@tuxteam.de wrote:
> On Tue, Jan 30, 2024 at 09:47:35PM +0100, hw wrote:
> > On Mon, 2024-01-29 at 18:41 +0100, to...@tuxteam.de wrote:
> > > On Mon, Jan 29, 2024 at 05:52:38PM +0100, hw wrote:
> > > 
> > > [...]
> > > 
> > > > Ok in that case, hardware RAID is a requirement for machines with UEFI
> > > > BIOS since otherwise their reliability is insufficient.
> > > 
> > > The price you pay for hardware RAID is that you need a compatible 
> > > controller
> > > if you take your disks elsewhere (e.g. because your controller dies).
> > 
> > How often do you take the system disks from one machine to another,
> > and how often will the RAID controller fail?
> > 
> > > With (Linux) software RAID you just need another Linux...
> > 
> > How's that supposed to help?  The machine still won't boot if the disk
> > with the UEFI partition has failed.
> 
> We are talking about getting out of a catastrophic event. In such cases,
> booting is the smallest of problems: use your favourite rescue medium
> with a kernel which understands your RAID (and possibly other details
> of your storage setup, file systems, LUKS, whatever).

Try to do that with a remote machine.

> [...]
> 
> > Maybe the problem needs to be fixed in all the UEFI BIOSs.  I don't
> > think it'll happen, though.
> 
> This still makes sense if you want a hands-off recovery (think data
> centre far away). Still you won't recover from a broken motherboard.

It would make sense that all the UEFI BIOSs would be fixed so that
they do not create this problem in the first place like they
shouldn't.

You seem to forget the point that one reason for using redundant
storage, like some kind of RAID, to boot from, is that I don't want to
have booting issues, especially not with remote machines.

Unfortunately UEFI BIOSs make that difficult unless you use hardware
raid.

And I don't want to have that problem with local machines either
because it's a really nasty problem.  How do you even restore the UEFI
partition when the disk it's on has failed and you don't have a copy?

Re: Probelms with apparmor

[Gareth Evans]

On Wed 31/01/2024 at 22:11, Steven Truppe  wrote:
> Hey,
>
>
> i've the follwoing trouble: when i try to run certain apps it takes
> forever tostart. i can get rid of the troble by typing $service apparmor
> reload but that's not a partmanent soutoin.
>
> can someone pleae help me out here ?
>
>
> best regards!

I accidentally replied to the OP, rather than the list, with the below:

Which apps?  

Is there any relevant output at the point at which a delay occurs, and perhaps 
just afterwards, if you start an affected program from the terminal?

I wonder if aa-complain may be of use to you, but first things first...

Thanks,
Gareth

Re: Probelms with apparmor

[Gareth Evans]

On Wed 31/01/2024 at 23:04, Gareth Evans  wrote:
> On Wed 31/01/2024 at 22:11, Steven Truppe  wrote:
>> Hey,
>>
>>
>> i've the follwoing trouble: when i try to run certain apps it takes
>> forever tostart. i can get rid of the troble by typing $service apparmor
>> reload but that's not a partmanent soutoin.
>>
>> can someone pleae help me out here ?
>>
>>
>> best regards!
>
> I accidentally replied to the OP, rather than the list, with the below:
>
> Which apps?  
>
> Is there any relevant output at the point at which a delay occurs, and 
> perhaps just afterwards, if you start an affected program from the 
> terminal?
>
> I wonder if aa-complain may be of use to you, but first things first...
>
> Thanks,
> Gareth

Also, anything relevant in /var/log/syslog or 

# journalctl --system ?

G

Re: chrony date months off

[Max Nikulin]

On 31/01/2024 20:24, didar wrote:

On Wed, Jan 31, 2024 at 05:32:26AM -0500, gene heskett wrote:

How do I setup /etc/chrony/chrony.conf so it slams the system clock to the
current time on the first cycle as its rebooting?
There was 20 yeas back, an ntpdate command that would do that.


You can use "rdate" (openrdate) as quick fix like `ntpdate'.
Is there a real reason to install an extra package if chrony provides a 
tool similar to ntpdate?


If I recall it right, the reason why chrony appeared here was just

$ man timesyncd
No manual entry for timesyncd

If it is that box with armbian modified by a Chinese 3d printer vendor 
then I am surprised that, intended for boards without RTC, it does not 
have proper NTP setup out of the box. Despite I expect arbitrary 
peculiarities in this kind of a Linux distribution, I still believe that 
NTP troubles were caused by user actions.

Re: Q: Gnome network odd

[David Wright]

On Tue 30 Jan 2024 at 07:05:55 (+), Tixy wrote:
> On Mon, 2024-01-29 at 23:49 -0600, David Wright wrote:
> > I would tend to think that:
> > 
> > . The debian-installer installs ifupdown by default when you don't
> >   install a Desktop Manager like Gnome,
> > 
> > . The debian-installer installs NetworkManager by default if you do
> >   install a Desktop Manager like Gnome,
> > 
> > . It shouldn't do both.
> > 
> 
> My experience, admittedly from a few releases ago, is that ifupdown is
> always installed but that the installer doesn't populate it's config
> files with the found network interfaces, only the loopback interface.

AIUI that would be normal behaviour when the DE installs its own
choice of package to handle the network.

But it's also what happens when you install over wifi and don't
select a DE: the wifi configuration is removed as the last step
in the installation process. It's a (mis)feature/bug that's been
discussed for years.

> I also have a more vague memory that you could put config into
> /etc/network/interfaces then in some circumstance NetworkManager would
> not try and manage that interface, and in others it would take over.
> (Perhaps selected by allow hotplug option in the ifupdown config?)

That seems unlikely. Perhaps you're thinking of NM's ifupdown plugin
that allows you to use the configuration in /e/n/i. I'm assuming the
OP has not installed that in their sleep. Max's request for printing
the configuration could confirm that.

Cheers,
David.

Re: chrony date months off

[gene heskett]

On 1/31/24 21:50, Max Nikulin wrote:

On 31/01/2024 20:24, didar wrote:

On Wed, Jan 31, 2024 at 05:32:26AM -0500, gene heskett wrote:
How do I setup /etc/chrony/chrony.conf so it slams the system clock 
to the

current time on the first cycle as its rebooting?
There was 20 yeas back, an ntpdate command that would do that.


You can use "rdate" (openrdate) as quick fix like `ntpdate'.
Is there a real reason to install an extra package if chrony provides a 
tool similar to ntpdate?


If I recall it right, the reason why chrony appeared here was just

$ man timesyncd
No manual entry for timesyncd

If it is that box with armbian modified by a Chinese 3d printer vendor 
then I am surprised that, intended for boards without RTC, it does not 
have proper NTP setup out of the box. Despite I expect arbitrary 
peculiarities in this kind of a Linux distribution, I still believe that 
NTP troubles were caused by user actions.


I'd argue that in the bigger picture, the edge distributions, some of 
which are one man operations or very close to it, like armbian, know 
these are often used in offline environments where it is not that 
important. But the minute you plug in the cat-# it is a different story. 
We are doing things with baby arm's that would normally take a 6 core i5 
to do, but doing it 1/4 as fast and on only 5% of the power.  That fast 
enough to get the job done, but lack of attention to what s/b just works 
stuff says bad code is still bad code. I'm finally understanding things 
the man pages will never tell you, about interdependentcy's. Once you 
begin to understand how timedatectl actually works, it all falls into 
place and just works.


My goal in much of this is to reduce my visibility on the net, so I now 
have only a one machine loading at pool.debian.org, instead of 5, soon 
to be 7. This machine has the power to be a server, so it now has a 
dhcpd server, specially configured to answer only one mac address, just 
to give an X-Max3 printer its hostname and net address.  I am also an 
ntp server, stratum 2, for the use of the rest of the machines on my 
local net. Yet each and every one has full net access.  With dd-wrt 
standing guard. I have only one registered address you can ping.  My 
original 20 gigabyte web page is down, left with the death of those 2 
seacrate 2T's in less than 30 days service about 2 days apart. But when 
it comes back it will be to support a woodworkers big bench vice I have 
designed, the screw is about 50mm by 500mm in hard maple, buttress 
thread, the reminder of it is printed in PETG for its resilience. 
Stronger grip than anything you can get on ebay. With one bigger 
printer, it takes about a day on the milling machine for the screw, but 
2+ weeks for the rest of the parts for a single screw.  That's why the 
push to build a (presently 3 bigger printers, was 4 till I lost the 
printheads umbilical cable on a creality e5-s1 and it is not a service 
part) farm.


Take care & stay well Max.

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: Can't list root directory

[Loren M. Lang]

On January 31, 2024 1:28:37 PM PST, hw  wrote:
>On Wed, 2024-01-31 at 09:27 -0500, Gary Dale wrote:
>> On 2024-01-30 15:54, hw wrote:
>> > On Mon, 2024-01-29 at 11:42 -0500, Gary Dale wrote:
>> > > I'm running Debian/Trixie on an AMD64 workstation. I've lost the ability
>> > > to see the root directory even when I am logged in as root (su -).
>> > > 
>> > > This has been happening intermittently for several months. I initially
>> > > thought it might be related to failing NVME drive that was part of a
>> > > RAID1 array that is mounted as "/" but I replaced the device and the
>> > > problem is still happening.
>> > > [...]
>> > What happens when you put the device you replaced back?
>> > 
>> How could putting a known-failing device back in help? The problem 
>> existed before I replaced it and continues to exist after the replacement.
>
>It sounded like you were able to list the root directory (at least
>sometimes) before you did the replacement.  Manually failing the
>device (perhaps after adding it back first) could make a difference.
>
>I've seen such indefinite hangs only when an NFS share has become
>unreachable after it had been mounted.  You could use clonezilla to
>make a copy and then perhaps convert the file system to btrfs.
>
>Do you still have the problem when you remove one of the NVME storage
>things?  Perhaps you have the equivivalent of a bad SATA cable or the
>mainboard doesn't like it when you access two of those at the same
>time, or something like that.  Even simple network cables can behave
>very strangely, and NVME may be a bit more complicated than that.
>
>Running fsck on every boot to work around an issue like this is
>certainly a bad idea.  Doesn't fsck report anything?  If it really
>makes a difference in itself rather than creating some side effect
>that leads to the root directory being readable, it should report
>something.  Perhaps you need to increase its verbosity.
>
>If there's no report then it would look like a side effect and raise
>the question what side effect it might be.  Does fsck run before the
>RAID has been brought up or after?  Is the RAID up when booting is
>completed?  What does mdadm say about the device(s)?  Can you still
>list the root directory when you manually fail either drive?  What
>exactly are the circumstances under which you can and not list the
>root directory?
>
>You need to do some investigating and ask questions like those ...
>

Also, instead of doing "ls -l /" which will stat() every child folder under 
root, try "/bin/ls -f /" and see if that is successful. That will only do a 
readdir() on root itself. Also, it might be interesting to get a log of "strace 
ls -l /" to confirm exactly where the hang happens.

-Loren 

-- 
Sent from my Nexus 4 with K-9 Mail. Please excuse my brevity.