Your message dated Tue, 22 Nov 2022 00:00:56 +0100
with message-id <20221121230056.laqn5kd6yfmsq...@percival.namespace.at>
and subject line Re: Bug#960452: mount: Editing fstab in a valid way causes
silent failure to mount
has caused the Debian Bug report #960452,
regarding mount: Editing fstab in a valid way causes silent failure to mount
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
960452: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960452
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: mount
Version: 2.33.1-0.1
Severity: important
There are multiple issues reflected in this report:
1) That mount failed to properly mount a filesystem;
2) That it incorrectly said it had mounted it;
3) That running systemctl daemon-reload fixed the issue;
4) That neither the mount nor the fstab manpages mentioned this interaction
I was recently migrating a server from LVM to md-raid. In the
process, I made a new filesystem on /dev/md0, mounted it on /mnt, and
copied /boot over to it on /mnt. I then unmounted /mnt and /boot,
edited fstab to reflect the new location, and tried to mount it on
/boot.
mount -v /boot responded:
mount: /dev/md0 mounted on /boot.
However, /boot was still empty. df didn't show that it was mounted
there, neither did /proc/mounts.
These commands all produced similar results:
mount -v /dev/md0 /boot
mount -t ext4 /dev/md0 /boot
However, this worked fine:
mount -v /dev/md0 /mnt
In other words, I could mount /dev/md0 at any location on the system
EXCEPT /boot. Any attempt to mount something at /boot would indicate
success but fail.
Eventually, on a lark, I tried systemctl daemon-reload. After that,
it mounted fine.
Related information:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907536 requests
documentation of the systemctl daemon-reload in fstab, but does not
address the incorrect behavior of mount.
https://github.com/systemd/systemd/issues/7291 states that the "raw
util-linux commands still honour /etc/fstab directly", but that does
not appear to be the case.
Thanks,
John
-- System Information:
Debian Release: 10.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages mount depends on:
ii libblkid1 2.33.1-0.1
ii libc6 2.28-10
ii libmount1 2.33.1-0.1
ii libselinux1 2.8-1+b1
ii libsmartcols1 2.33.1-0.1
ii util-linux 2.33.1-0.1
mount recommends no packages.
Versions of packages mount suggests:
ii nfs-common 1:1.3.4-2.5
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 2.38-1
I've discovered today upstream has added a hint for this into
mount itself:
https://github.com/util-linux/util-linux/commit/1db0715169954a8f3898f7ca9d3902cd6c27084d
I believe in the described situation mount will now show this
hint:
mount: (hint) your fstab has been modified, but systemd still uses
the old version; use `systemctl daemon-reload` to reload.
At least thats what I saw in similar situations in unstable today.
I consider this problem "fixed". Let me know if you disagree.
Best,
Chris
--- End Message ---
