On Fri, May 13 2016, Laurent Bigonville <bi...@debian.org> wrote: > Again this is supposed to happen at early boot, and at this stage, only > PID1 exists. So I doubt there is a lot of concurrent processes at that time.
But this is not checked in the source. In fact, this behavior will happen irregardless of the boot stage. >> Even if the fix is simply the removal of the mountpoint, I consider the >> solution broken by design. > What about mounting /proc really early? I can say the same about initramfs. Can't initramfs just mount /proc sooner and fix the problem correctly? > Mount failed for selinuxfs on /sys/fs/selinux: No such file or > directory > > To fix this, mount the procfs before attempting to open > /proc/filesystems, and unmount it when done if it was initially not > mounted. This is the same thing that selinux_init_load_policy() does > when reading /proc/cmdline. > > If you think you know a better way, please provide a patch to upstream. The thing is that I *don't* use SElinux, and this is why I see it as a regression, and the main reason I don't really want to look at *another* source tree for this. Maybe upstream is fixing this for distributions that have a poor booting sequence. Incorrectly. The patch might actually fix something if selinux is enabled, but regresses in behavior for other scenarios where selinux is not used. The fact that I was able to notice, you have to admit, is an indication that there are cases where it is /not/ ok. > I'll not carry a patch in debian and make libselinux behave differently > than on 99% of the other distributions. I, honestly, expected someone that understand the issue to help and chime to report it upstream.