mount: (hint) your fstab has been modified, but systemd still uses the old version; use 'systemctl daemon-reload' to reload.

[reraikes]

Using: image_2023-09-22-raspios-bookworm-arm64-lite.img

pi@raspberrypi:~ $ sudo mount /dev/mmcblk0p1 /mnt
mount: (hint) your fstab has been modified, but systemd still uses
the old version; use 'systemctl daemon-reload' to reload.

'systemctl daemon-reload' resolves the problem until the next reboot.

For additional info, see: https://forums.raspberrypi.com/viewtopic.php?p=2140308

[mgroff2]

I am running into this and cant gain access to that forum even create and activating account. Any update?

[XECDesign]

Aside from seeing the message? Does it cause any issues? As far as I know, if there is no RTC, systemd uses the time of when its current version was released and notices that drop in services were modified after that. I may be wrong, but I think it's a harmless message and is a problem with systemd rather than any modification we've made.

[mgroff2]

@XECDesign it's persisting through reboots. I am forced to manually login after a reboot and mount instead of expecting fstab to work.

[XECDesign]

Does running sudo update-initramfs -u -k all and rebooting make it work?

[Identifier]

Still happening as of October 2024, even after performing sudo apt --reinstall install mount and sudo update-initramfs -u -k all

In my case it happens every time I do sudo mount -o remount,ro / or sudo mount -o remount,rw, even though it doesn't actually modify the /etc/fstab file. The "hint" is really pointless.

[marcone]

The source code for mount shows that that message is printed when /etc/fstab is newer than /run/systemd/systemd-units-load.

It seems the latter gets created during early boot when the proper system time hasn't been set yet, and so its modification time will be set to some arbitrary time that is likely before the modification time of /etc/fstab.

A workaround might be to touch /run/systemd/systemd-units-load once the real system time is set, or at least set its modification time to a time that is greater or equal to that of /etc/fstab.

[lurch]

The source code for mount shows that that message is printed when /etc/fstab is newer than /run/systemd/systemd-units-load.

It seems the latter gets created during early boot when the proper system time hasn't been set yet, and so its modification time will be set to some arbitrary time that is likely before the modification time of /etc/fstab.

Ahh, good find! So I guess this is actually a mount problem (and the way that it interacts with systemd) rather than directly a systemd problem.

A workaround might be to touch /run/systemd/systemd-units-load once the real system time is set,

That won't work if the Pi doesn't have an internet connection.

or at least set its modification time to a time that is greater or equal to that of /etc/fstab.

This seems like a plausible suggestion. I'm not familiar with systemd myself, but maybe one of the other Raspberry Pi engineers will be able to have a look next year (most of us are now off for Christmas).
Hmmm, although the fake-hwclock package should already deal with this scenario, so perhaps the real problem is that /run/systemd/systemd-units-load gets created before fake-hwclock has set the time to something sensible? 🤔

[marcone]

Hmmm, although the fake-hwclock package should already deal with this scenario, so perhaps the real problem is that /run/systemd/systemd-units-load gets created before fake-hwclock has set the time to something sensible? 🤔

Yes, systemd-units-load is created when systemd starts loading units, and since fake-hwclock is one of those units, it will start after that file is created. Perhaps an additional Raspberry Pi specific service that starts after fake-hwclock could either touch /run/systemd/systemd-units-load or systemctl daemon-reload (the latter doesn't appear to actually restart any services, so shouldn't result in a loop, but I haven't actually tried it).

Also for the official prebuilt images, it might be sufficient to touch -t 197001010000 /etc/fstab in the final build stage. That way /etc/fstab wil always be older than systemd-units-load, and you can do things like mount -o remount,... without seeing the warning message.

[lurch]

Perhaps an additional Raspberry Pi specific service that starts after fake-hwclock could either touch /run/systemd/systemd-units-load

Sounds like a reasonable suggestion.
(But just to clarify, I believe this would affect any platform that uses systemd and doesn't have an RTC, i.e. it's not entirely "Raspberry Pi specific")

Also for the official prebuilt images, it might be sufficient to touch -t 197001010000 /etc/fstab in the final build stage.

Urgh, that sounds like a horrible suggestion 🤢 🤣 Also, that "solution" would break as soon as somebody edits /etc/fstab.

[puterboy]

Problem still exists at Dec 2024.
Clearly Bookworm broke something so shouldn't be too hard for maintainers to revert the changes that broke this.