When using <openrc-0.10 I get a mounted system like the following: rc-svcdir on /lib64/rc/init.d type tmpfs (rw,rootcontext=system_u:object_r:initrc_state_t,seclabel,nosuid,nodev,noexec,relatime,size=1024k,mode=755) rc-svcdir on /lib64/rc/init.d type ramfs (rw,nosuid,nodev,noexec,relatime) The ramfs overlays the tmpfs (causing the selinux context to be lost). It looks like it's because the /lib64/rc/sh/init.sh script gets run twice for some reason and the logic is setup so that if there is a problem mounting tmpfs (which there will be the second time due to already being mounted); the fall through logic mounts a ramfs on top of the previous location. I've asked around and looked at other systems to try and verify this but have only verified it on xenU rc_sys types (xen guests). Reproducible: Always Steps to Reproduce: 1.emerge \<openrc-0.10 2.reboot 3.mount | grep rc-svcdir | wc -l Actual Results: The above will provide two lines (for sure on a xenU system). Expected Results: The above should provide one line, <openrc-0.10, and zero lines for >=openrc-0.10 Again, I believe this is only when specifying the rc_sys="xenU" but haven't been able to prove this to myself. The critical piece of this and the only reason I found it is because this breaks the selinux contexts and certain RC events start getting denied by selinux with this behavior.
Please test and re-open if this is an issue with >=openrc-0.10. Thanks much.
I've already tested with >=openrc-0.10 and there are no problems but at the sametime there was and is no stable openrc other than 0.9.8.4. Is there a stabilization of any >=openrc-0.10 coming soon to solve this bug?
