Description of problem: The portion of systemd that handles API mounts initially mounts filesystems with hardcoded options, meaning they later have to be remounted by systemd-remount-api-vfs when the options given in fstab differ. While there is no getting around remounting filesystems mounted in the initramfs, systemd has access to fstab and might as well consult it when determining how to mount whichever API filesystems that appear there. This is related to, but not the cause of, a recent devel list thread [1]. The cause is a different bug where systemd-remount-api-vfs doesn't seem to work properly [2]. [1] http://lists.fedoraproject.org/pipermail/devel/2010-December/147080.html [2] http://lists.fedoraproject.org/pipermail/devel/2010-December/147142.html Version-Release number of selected component (if applicable): systemd-15-1.fc15.x86_64
Hmm, weird, this works fine here. If I invoke /lib/systemd/systemd-remount-api-vfs manually as root all settings from /etc/fstab are properly applied. I added and removed a "noexec" from the /dev/shm line and it always got properly applied to the mount options of /dev/shm by invoking /lib/systemd/systemd-remount-api-vfs. Can anybody reproduce the issue with /lib/systemd/systemd-remount-api-vfs started manually? If you can, could you run "strace -f -e execve /lib/systemd/systemd-remount-api-vfs" to see whether /bin/mount is properly invoked by the tool for your mount point? If it is invoked, then the bug is presumably in mount, not in systemd. Hmm, thinking about it here's my (educated) guess what really was going on: systemd does not clean up /etc/mtab, because we want this to be replaced by a symlink to /proc/mounts, a change which will happen shortly in the util-linux package but so far has not been made yet. So, because mtab wasn't cleaned up it still included (mutliple) /dev/shm entries from a previous boot. When systemd-remount-api-vfs invoked /bin/mount the latter found those entries and was confused and got tricked into not actually applying the mount options from /etc/fstab because it assumed they already were there. Or something like that. Karel, can you comment whether this explanation makes any sense at all? If it does then an update to util-linux which includes the symlink should fix this problem for good.
(And of course, if this is indeed the right explanation then replacing /etc/mtab by a symlink to /proc/self/mounts should fix it.)
OK, closing due to lack of response. I presume anyway that this is fixed by mount installing /etc/mtab as symlink now. Feel free to reopen if this problem continues to exist.