On a stable system I'm using openrc-0.19.1 and I have a /usr partition. I have an initrd which mount /usr before init start. Since many months (and many openrc versions), I can see the following messages at the very end of each reboot or shutdown sequences : * Remounting remaining filesystems read-only ... * Remounting /usr read only ... [!!] * failed because we are using /usr [!!] * Remounting / read only * ERROR: mount-ro failed to start Do you know a way to determine what's going on please ? Thanks.
Created attachment 424690 [details, diff] mount-ro.patch This patch makes mount-ro ignore /usr if it was not mounted by OpenRC. Please test and let me know if it fixes your issue. Thanks, William
Yes, the error is gone. Patch applied and got this : * Remounting remaining filesystems read-only ... * Remounting / read only [ok] But I know that some people are using some more complex setups with other pre-mounted mount points, for example, like /var. So /usr may not be the only mount point affected by this. Thanks !
(In reply to Fab from comment #2) > Yes, the error is gone. Patch applied and got this : > > * Remounting remaining filesystems read-only ... > * Remounting / read only [ok] > > But I know that some people are using some more complex setups with other > pre-mounted mount points, for example, like /var. So /usr may not be the > only mount point affected by this. This is a good point, so I'm now wondering if mount-ro should even try to do this, or if just running sync on the way down to flush everything to disk is sufficient?
If you ask it to me, my response would be « I don't know ». By coincidence, bug #573922 (and respective debate on -dev ML ) was opened. When I installed this system, udev was the default (eudev does not even exist), and anyway my politic was always to follow the default choice in virtual packages. I will wait for results, but in this particular case perhaps I will switch to eudev. This means that an initrd which pre-mounts /usr would no longer be mandatory, so I could simply get rid of my initrd and this bug should automagically vanish.
(In reply to Fab from comment #4) *snip* > When I installed this system, udev was the default (eudev does not even > exist), and anyway my politic was always to follow the default choice in > virtual packages. I will wait for results, but in this particular case > perhaps I will switch to eudev. > > This means that an initrd which pre-mounts /usr would no longer be > mandatory, so I could simply get rid of my initrd and this bug should > automagically vanish. That's a misconception, because the system guys happened to mention it first. Udev has nothing to do with the initramfs pre-mounting /usr. Systemd was the first major package to tell you about it, but splitting / from /usr is definitely not a good idea for many reasons without an initramfs, so please do not think that switching to eudev will make that a non-issue.
In case this is useful, systemd has addressed this issue in part by letting the initramfs unmount /usr and / if possible. I know this is the behavior when using dracut. I don't know the details of how this is coordianted between the initramfs and systemd, but we obviously control genkernel and I suspect that dracut would accept patches if necessary to enable this kind of support for openrc. This allows both root and /usr to be unmounted cleanly, whether read-only or otherwise.
@rich0: I think you are talking about bug #524404, which is a fix for sysvinit. I haven't looked into it heavily, but the idea is that, as the last step of going down, sysvinit should exec another process in its place that shuts everything down and remounts all mounted file systems read only.
I have the same issue. Seperate /usr that is mounted in initramfs and on reboot or shutdown the error message is displayed unable to mount /usr read only. I tried the patch and the Error message went away. It appears that this is only suppressing the error message and that /usr is not remounted read-only for a clean shutdown? Is this something that openrc needs to handle or the initramfs should mount unmount so openrc can mount it at boot runlevel?
*** Bug 577530 has been marked as a duplicate of this bug. ***
https://github.com/openrc/openrc/commit/bf539f2 This will skip the remounting of /usr ro if /usr was premounted. I will include it in 0.23 and backport to 0.22.3.
Hi there, about 8 years later.... I believe the fix introduced here is incorrect. Being able (or not) to unmount /usr or remount it read-only by OpenRC, has nothing to do with the way how it was mounted. The real problem is that OpenRC uses "umount -r" instead of "mount -o remount,ro" which is very fine alone, but combined with a regression introduced in util-linux about 10 years ago that broke "umount -r" for non-root filesystems, prevents busy /usr (which should be very expected these days) from being re-mounted read-only. The end result of excluding /usr based on the usr_premounted condition is that while there is no warning during a shutdown, we leave the filesystem in a non-clean state, so the next time system boots the /usr filesystem still has errors and needs to be fixed, which may even lead into data loss. This bug has been just fixed in the upstream: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=a20e7e23a8565e01b1c84de6924d1fbbdb1cfccc Please also see https://lore.kernel.org/all/1350349b-8465-4ce6-8dc9-55a32b84dc39@ans.pl/T/#t or https://www.spinics.net/lists/util-linux-ng/msg17699.html for more details. With this fix OpenRC is able to remount /usr read-only on shutdown, which then leaves the filesystem in a clean state: * Remounting remaining filesystems read-only ... * Remounting /usr read only ... [ ok ] * Remounting / read only ... [ ok ] [ ok ] [ 200.168239] reboot: Restarting system Sam, William do you think it would be possible to cherry-pick that fix into the sys-apps/util-linux-2.39.3 ebuild (-r8?) and release a new OpenRC (with a proper dependency in portage) with https://github.com/OpenRC/openrc/commit/bf539f2196290864ce5c5fd0d679b74ee016e2da reverted? Also, as I cannot re-open this bug, could you please advise if I should file a new one, or you can help with re-opening?
Reopening for visibility.
We now have util-linux-2.40.1 in the tree (via https://bugs.gentoo.org/931297, not sure if there is a better bug for the bump?) with the "umount -r" fix.
(In reply to Krzysztof Olędzki from comment #11) > Hi there, about 8 years later.... > Ugh, sorry, I missed this until now. Please feel free to email me or ping me on IRC if you think there's something I should at least comment on (at least if nobody else has). I'll take a look - thank you!
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=575b2c990c42dca1c38973906f9839c3c0efbf06 commit 575b2c990c42dca1c38973906f9839c3c0efbf06 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-05-09 23:47:48 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-05-09 23:47:48 +0000 sys-apps/util-linux: backport umount --read-only fix to 2.39.x Bug: https://bugs.gentoo.org/573760 Signed-off-by: Sam James <sam@gentoo.org> .../files/util-linux-2.39.4-umount-readonly.patch | 35 ++ sys-apps/util-linux/util-linux-2.39.4-r1.ebuild | 417 +++++++++++++++++++++ 2 files changed, 452 insertions(+)
(In reply to Krzysztof Olędzki from comment #11) > Hi there, about 8 years later.... > > I believe the fix introduced here is incorrect. Being able (or not) to > unmount /usr or remount it read-only by OpenRC, has nothing to do with the > way how it was mounted. > > The real problem is that OpenRC uses "umount -r" instead of "mount -o > remount,ro" which is very fine alone, but combined with a regression > introduced in util-linux about 10 years ago that broke "umount -r" for > non-root filesystems, prevents busy /usr (which should be very expected > these days) from being re-mounted read-only. > > The end result of excluding /usr based on the usr_premounted condition is > that while there is no warning during a shutdown, we leave the filesystem in > a non-clean state, so the next time system boots the /usr filesystem still > has errors and needs to be fixed, which may even lead into data loss. > > This bug has been just fixed in the upstream: > https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/ > ?id=a20e7e23a8565e01b1c84de6924d1fbbdb1cfccc > > Please also see > https://lore.kernel.org/all/1350349b-8465-4ce6-8dc9-55a32b84dc39@ans.pl/T/#t > or https://www.spinics.net/lists/util-linux-ng/msg17699.html for more > details. > > With this fix OpenRC is able to remount /usr read-only on shutdown, which > then leaves the filesystem in a clean state: > * Remounting remaining filesystems read-only ... > * Remounting /usr read only ... > [ ok ] > * Remounting / read only ... > [ ok ] > [ ok ] > [ 200.168239] reboot: Restarting system > > Sam, William do you think it would be possible to cherry-pick that fix into > the sys-apps/util-linux-2.39.3 ebuild (-r8?) and release a new OpenRC (with > a proper dependency in portage) with > https://github.com/OpenRC/openrc/commit/ > bf539f2196290864ce5c5fd0d679b74ee016e2da reverted? > Backported into 2.39.4-r1. As for OpenRC, I'm not sure what the best thing to do is, and I defer to William. It's tricky though because other distros which use OpenRC may not have a fixed util-linux...
