After I recently updated genkernel and built a new kernel, I found that the system didn't boot correctly anymore. The kernel boots fine, but many OpenRC services fail to start and no input devices work in Xorg. After some debugging, I found this was caused by missing SElinux root context in /run. As stated in the documentation, /run requires setting the correct root context for /run: https://wiki.gentoo.org/wiki/SELinux/Installation#Setting_file_system_contexts This was not an issue in previous of genkernel because it just didn't mount /run, but commit c792697d for bug #706434 introduced this line in defaults/linuxrc: mount -t tmpfs -o rw,nosuid,nodev,relatime,mode=755 none /run 2>&1 This is what caused the issue by missing SELinux root context for /run. Modifying this line to add the missing mount options fixed the issue for me: mount -t tmpfs -o rw,nosuid,nodev,relatime,mode=755,rootcontext=system_u:object_r:var_run_t none /run 2>&1 As far as I know, that option would be ignored for non-SELinux system, so it would be safe for them to add it unconditionally. Not sure about MLS or MCS systems since the required parameter mentioned by the documentation is slightly different.
I am not sure if the initramfs should mount /run with SElinux options. Instead I believe that the real system should fix mount like it will re-mount root for example. Do you have /run with your desired options in /etc/fstab?
(In reply to Thomas Deutschmann from comment #1) > I am not sure if the initramfs should mount /run with SElinux options. Actually, it doesn't work as I described it. I didn't notice that by adding the SELinux parameters the mount was failing with the following message: SELinux: Unable to set superblock options before the security server is initialized mount: mounting non on /run failed: Invalid argument So what I did when I thought I was mounting /run from the initramfs with the SELinux options was actually reverting back to the old behaviour before c792697d of not mounting /run from the initramfs by making it fail. > Instead I believe that the real system should fix mount like it will > re-mount root for example. > > Do you have /run with your desired options in /etc/fstab? Yes, I have the correct options in my /etc/fstab as described in the documentation: tmpfs /run tmpfs mode=0755,nosuid,nodev,rootcontext=system_u:object_r:var_run_t 0 0 But the real system doesn't really remount /run but mount it again over the existing one ending up with two /run mounts when: # fgrep ' /run ' /proc/mounts none /run tmpfs rw,seclabel,nosuid,nodev,relatime,mode=755 0 0 tmpfs /run tmpfs rw,rootcontext=system_u:object_r:var_run_t,seclabel,nosuid,nodev,relatime,mode=755 0 0 The first one is the one mounted by the initramfs and the second one is the one mounted by the real system. If the first one is omitted, the issue is gone.
This sounds like a bug in OpenRC. As small test: Please install dracut and run it (note: it will use same initramfs name like genkernel) and see if it will do anything different (at the moment I cannot spot a special SElinux handling and mount options for /run are the same like we use in genkernel).
I tried with dracut as requested and the issue is not happening (i.e., an unmodified dracut initramfs boots the system with no issues). But what's weirder is that this time /run is mounted only once without the options in /etc/fstab: # fgrep /run /etc/fstab tmpfs /run tmpfs mode=0755,nosuid,nodev,rootcontext=system_u:object_r:var_run_t 0 0 # fgrep ' /run ' /proc/mounts tmpfs /run tmpfs rw,seclabel,nosuid,nodev,noexec,mode=755 0 0 #
OpenRC only mounts /run if it is not already mounted. However, it runs restorecon -rF /run regardless of whether it mounted /run or not. OpenRC does not respect fstab options for /run in the initial mount. See [1] for implementation as of this writing. The root initscript will remount /run with fstab options after remounting / read-write if /run is listed in fstab, though.[2] [1]: https://github.com/OpenRC/openrc/blob/5427783/sh/init.sh.Linux.in#L70 [2]: https://github.com/OpenRC/openrc/blob/9bd63b5/init.d/root.in#L48
(In reply to Jesús P Rey (Chuso) from comment #4) > I tried with dracut as requested and the issue is not happening (i.e., an > unmodified dracut initramfs boots the system with no issues). Could you please run dracut in debug mode? This should create a log what dracut did. Maybe we see some magic...
Created attachment 660042 [details] Dracut debug log Sure, here it is.
Sorry for the wrong MIME type, I set it to text/plain but I had to gzip it because it was too big and forgot to change the MIME type.
After upgrading to sys-kernel/genkernel-4.1.2-r3 I'm also seeing problems with OpenRC services on boot on two selinux machines, particularly and weirdly OpenRC runs each service 2 or 3 times on bootup. I also see the two /run mounts exactly like the OP, and I have no input devices working in Xorg on one of the machines which runs X desktops. I'm going to try changing the mount command in the initramfs like the OP did and will confirm later today if it resolves for me. Also, bug 739424 seems like it is related.
@ Jesús P Rey (Chuso): You showed a debug log from dracut creating the initramfs. I meant the dracut _boot_ log in debug mode. What I did in the past: 1) I compiled a kernel with SELinux support. 2) I am still not using a SELinux profile. I rebooted with 'security=selinux' added to kernel command-line and confirmed permissive mode via `getenforce`. I was unable to spot any problems. /run content was preserved and accessible. My network devices came up. Just opentmpfiles service failed in all run levels. So without proper labeling properly not a useful test scenario. From reading dracut source code, https://github.com/dracutdevs/dracut/blob/051/modules.d/98selinux/selinux-loadpolicy.sh, I spot the following differences: 1) They use mount from util-linux (genkernel uses mount from busybox). On systems using SELinux profile, util-linux probably links against libselinux.so with the result that mount (and switch_root) are SELinux-aware. 2) They call /sbin/load_policy before switch_root. At this point I am not sure how to proceed. Because I don't use SELinux I am not willing to spend time on adding proper SELinux support. Something genkernel never had before. Never had before? But it worked for me with <genkernel-4.1.0! Right, but we never had explicit SELinux support. It worked somehow because /run wasn't preserved. I am thinking about adding an option to genkernel which will unmount /run before switch_root which should restore previous state from <genkernel-4.1.0. However, this will cause bug 706434 again for LVM users on systemd (same like <genkernel-4.1.0).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/genkernel.git/commit/?id=ab6d73225f21be7d55649363ceb460d91270638d commit ab6d73225f21be7d55649363ceb460d91270638d Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2021-02-08 01:25:50 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2021-02-08 21:20:28 +0000 linuxrc: Add gk.preserverun.disabled When this boolean option is set and enabled, genkernel initramfs will unmount /run before calling switch_root. This can help in SELinux context for example where labeling is required which is not supported by genkernel. Bug: https://bugs.gentoo.org/739424 Bug: https://bugs.gentoo.org/740576 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> defaults/initrd.defaults | 1 + defaults/linuxrc | 15 +++++++++++ doc/genkernel.8.txt | 6 +++++ ....1-switch_root-check-if-mountpoint-exists.patch | 31 ++++++++++++++++++++++ 4 files changed, 53 insertions(+)
*** Bug 739424 has been marked as a duplicate of this bug. ***
The following commit attempts to rework the /run setup for linux systems to clean up this issue. https://github.com/OpenRC/openrc/commit/5f890ee8ab94f8760f4840d280feb7eced999068 This will be included in 0.43. If it doesn't fix the issue and there's something else I can do to help in OpenRC please open a new bug. Thanks, William
