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:
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
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:
clock" but the fix is not provided.