I have added a line to /etc/fstab: /dev/mapper/imgs /mnt/imgs ext4 noauto,noexec,nodev 0 0
I have run "systemctl daemon-reload"
After a reboot, the command "mount /mnt/imgs" still returns the message: Mount: (hint) your fstab has been modified, but systemd still uses the old version; use 'systemctl daemon-reload' to reload.
This is Fedora 36, fully updated. What am I missing?
On 20 Aug 2022, at 19:16, Robert Nichols rnicholsNOSPAM@comcast.net wrote:
I have added a line to /etc/fstab: /dev/mapper/imgs /mnt/imgs ext4 noauto,noexec,nodev 0 0
I have run "systemctl daemon-reload"
After a reboot, the command "mount /mnt/imgs" still returns the message: Mount: (hint) your fstab has been modified, but systemd still uses the old version; use 'systemctl daemon-reload' to reload.
This is Fedora 36, fully updated. What am I missing?
I would do an ls -l of the file and check the size and date. Does it seems to be changed since the system booted?
Barry
-- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 8/20/22 4:56 PM, Barry wrote:
On 20 Aug 2022, at 19:16, Robert Nichols rnicholsNOSPAM@comcast.net wrote:
I have added a line to /etc/fstab: /dev/mapper/imgs /mnt/imgs ext4 noauto,noexec,nodev 0 0
I have run "systemctl daemon-reload"
After a reboot, the command "mount /mnt/imgs" still returns the message: Mount: (hint) your fstab has been modified, but systemd still uses the old version; use 'systemctl daemon-reload' to reload.
This is Fedora 36, fully updated. What am I missing?
I would do an ls -l of the file and check the size and date. Does it seems to be changed since the system booted?
Barry
No, it hasn't been changed, but after yet aother round of "systemctl daemon-reload; reboot", the message finally went away.
Thanks for letting me know that what I was doing should be sufficient.
On 8/20/22 6:23 PM, Robert Nichols wrote:
On 8/20/22 4:56 PM, Barry wrote:
On 20 Aug 2022, at 19:16, Robert Nichols rnicholsNOSPAM@comcast.net wrote:
I have added a line to /etc/fstab: /dev/mapper/imgs /mnt/imgs ext4 noauto,noexec,nodev 0 0
I have run "systemctl daemon-reload"
After a reboot, the command "mount /mnt/imgs" still returns the message: Mount: (hint) your fstab has been modified, but systemd still uses the old version; use 'systemctl daemon-reload' to reload.
This is Fedora 36, fully updated. What am I missing?
I would do an ls -l of the file and check the size and date. Does it seems to be changed since the system booted?
Barry
No, it hasn't been changed, but after yet aother round of "systemctl daemon-reload; reboot", the message finally went away.
Thanks for letting me know that what I was doing should be sufficient.
Well, it's back, and nothing I do will get rid of that message. I can run "systemd daemon-reload" for a temporary fix, but as soon as I reboot, any action such as a remount that references /etc/fstab still results in that same "systemd still uses the old version" message.
The timestamp shows that /etc/fstab has not been modified since the last several reloads. I have run "systemctl daemon-reload" many times since the last fstab modification. Do I need to cause that to be run automatically on each boot?
This is getting annoying.
On 9/3/22 10:21 PM, Robert Nichols wrote:
On 8/20/22 6:23 PM, Robert Nichols wrote:
On 8/20/22 4:56 PM, Barry wrote:
On 20 Aug 2022, at 19:16, Robert Nichols rnicholsNOSPAM@comcast.net wrote:
I have added a line to /etc/fstab: /dev/mapper/imgs /mnt/imgs ext4 noauto,noexec,nodev 0 0
I have run "systemctl daemon-reload"
After a reboot, the command "mount /mnt/imgs" still returns the message: Mount: (hint) your fstab has been modified, but systemd still uses the old version; use 'systemctl daemon-reload' to reload.
This is Fedora 36, fully updated. What am I missing?
I would do an ls -l of the file and check the size and date. Does it seems to be changed since the system booted?
Barry
No, it hasn't been changed, but after yet aother round of "systemctl daemon-reload; reboot", the message finally went away.
Thanks for letting me know that what I was doing should be sufficient.
Well, it's back, and nothing I do will get rid of that message. I can run "systemd daemon-reload" for a temporary fix, but as soon as I reboot, any action such as a remount that references /etc/fstab still results in that same "systemd still uses the old version" message.
The timestamp shows that /etc/fstab has not been modified since the last several reloads. I have run "systemctl daemon-reload" many times since the last fstab modification. Do I need to cause that to be run automatically on each boot?
This is getting annoying.
And, here I am the next morning and everything is working fine with no messages.
Here's what I believe must be happening. Because this affected system is dual-boot with MS-Windows, the hardware clock is in local time. During boot, systemd must be syncing /etc/fstab before the system clock has been adjusted to UTC. My timezone offset is -5 hours, so if /etc/fstab was modified less than 5 hours before the reboot, systemd will later see it as "newer" than what it synced.
I don't fully understand what I just wrote, but that has to be the gist of what is happening.
This oddball case of a few warning messages probably isn't worth anyone's time to fix.
On Sun, Sep 4, 2022 at 10:17 AM Robert Nichols rnicholsNOSPAM@comcast.net wrote:
On 9/3/22 10:21 PM, Robert Nichols wrote:
On 8/20/22 6:23 PM, Robert Nichols wrote:
On 8/20/22 4:56 PM, Barry wrote:
On 20 Aug 2022, at 19:16, Robert Nichols rnicholsNOSPAM@comcast.net
wrote:
I have added a line to /etc/fstab: /dev/mapper/imgs /mnt/imgs ext4 noauto,noexec,nodev 0 0
I have run "systemctl daemon-reload"
After a reboot, the command "mount /mnt/imgs" still returns the
message:
Mount: (hint) your fstab has been modified, but systemd still uses the old version; use 'systemctl daemon-reload' to reload.
This is Fedora 36, fully updated. What am I missing?
I would do an ls -l of the file and check the size and date. Does it seems to be changed since the system booted?
Barry
No, it hasn't been changed, but after yet aother round of "systemctl daemon-reload; reboot", the message finally went away.
Thanks for letting me know that what I was doing should be sufficient.
Well, it's back, and nothing I do will get rid of that message. I can
run "systemd daemon-reload" for a temporary fix, but as soon as I reboot, any action such as a remount that references /etc/fstab still results in that same "systemd still uses the old version" message.
The timestamp shows that /etc/fstab has not been modified since the last
several reloads. I have run "systemctl daemon-reload" many times since the last fstab modification. Do I need to cause that to be run automatically on each boot?
This is getting annoying.
And, here I am the next morning and everything is working fine with no messages.
Here's what I believe must be happening. Because this affected system is dual-boot with
MS-Windows, the hardware clock is in local time. During boot, systemd must
be syncing
/etc/fstab before the system clock has been adjusted to UTC. My timezone
offset is -5 hours,
so if /etc/fstab was modified less than 5 hours before the reboot, systemd
will later see it as
"newer" than what it synced.
With Windows 10, you should be able to use UTC for the system clock. The issue also affects dual-boot with macOS. As is often the case, arch linux has the best documentation: arch linux has the best documentation https://wiki.archlinux.org/title/System_time#UTC_in_Microsoft_Windows.
I don't fully understand what I just wrote, but that has to be the gist of
what is happening.
This oddball case of a few warning messages probably isn't worth anyone's time to fix.
"It is strongly discouraged to set a non-UTC time zone for reasons including, but not limited to, time zone confusions, complexities of adjusting clocks for daylight savings time depending on regional customs, difficulty in correlating log files across systems, possibility of a stale time zone database, and unpredictability, as local time zones are subject to arbitrary local policies and laws. " -- Fedora Project Configuring Time Zone <https://docs.fedoraproject.org/en-US/fedora-coreos/time-zone/Fedora Project Configuring Time Zone>
For every person who reports a problem like this there are dozens if not hundreds who never report the problem. Many will discover outdated or incorrect advice from the internet. Some will decide that linux doesn't work and stick with Windows.
There is a simple and effective solution, but it is buried under a mass of internet garbage, for example:
itsfoss.com: wrong-time-dual-boot https://itsfoss.com/wrong-time-dual-boot/ mentions "Make Windows use UTC time for the hardware clock" but the fix is not provided.
On Mon, 2022-09-05 at 11:06 -0300, George N. White III wrote:
For every person who reports a problem like this there are dozens if not hundreds who never report the problem. Many will discover outdated or incorrect advice from the internet. Some will decide that linux doesn't work and stick with Windows.
There is a simple and effective solution, but it is buried under a mass of internet garbage, for example:
itsfoss.com: wrong-time-dual-boot/ mentions "Make Windows use UTC time for the hardware clock" but the fix is not provided.
I think a large part of the inertia on doing much about this is, is that other than at boot time the hardware clock is generally ignored, giving a prevailing attitude that the program is fixed elsewhere.
Often it is, the clock will simply be set sometime during boot. It doesn't help you with log files, but the general public doesn't look at them. Though sometimes clocks will be so far out of time that automatic systems abort trying to set them. Windows has got better at managing itself over a daylights savings change, but still stuffs it up under some circumstances. For some people they won't care that the computer's clock is mis-set, until things they want to do over the internet foul up.