On Sun, Sep 4, 2022 at 10:17 AM Robert Nichols <rnicholsNOSPAM(a)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(a)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.
--
George N. White III