Description of problem:
My system refuses to boot, see attachment. I don't use SELinux, so it must be something else. Rootfs appears to be mounted ro
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Created attachment 489137 [details]
systemd-v21 failed boot
Interesting that it complains about the read-only filesystem when touching /var/lock/subsys/local because /var/lock is supposed to be a bind-mount of /run/lock which is a tmpfs.
Something important must have failed earlier than what we see on the screenshot.
Can you at least boot with the "emergency" boot parameter?
Ok, source of the problem was SELinux that is not installed on my system at least I thought so.
I tried emergency and emergency.target as boot parameters but it did not work.
I'll check that dirs.
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
tmpfs on /var/run type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
seems to be ok
(In reply to comment #3)
> Ok, source of the problem was SELinux that is not installed on my system at
> least I thought so.
Now I am confused. Please state clearly what SELinux state your system is using (disabled, permissive, or enforcing).
> I tried emergency and emergency.target as boot parameters but it did not work.
It's simply "emergency". If you want to be verbose, the equivalent is "systemd.unit=emergency.target".
How exactly did it not work? What was the result?
I am seeing this boot failiure as well. Updated everything yesterday. After
update the system already hung on trying to reboot. Then it hung on boot. It
seemed to hang at different points, with screens similar as above, though the
graphics would sometimes get messed up. When hung the console was still
scrollable, so the system was not hung completely. Everything is stock really
so selinux is where it is by default. The system did manage to boot into
"single" and so I downgraded to the last systemd-v20 package (nothing else) and
the system now boots and works fine, so it is definitely the systemd update
(In reply to comment #5)
> (In reply to comment #3)
> > Ok, source of the problem was SELinux that is not installed on my system at
> > least I thought so.
> Now I am confused. Please state clearly what SELinux state your system is using
> (disabled, permissive, or enforcing).
It's disabled, but it works... It's a SELinux bug
> > I tried emergency and emergency.target as boot parameters but it did not work.
> It's simply "emergency". If you want to be verbose, the equivalent is
> How exactly did it not work? What was the result?
Result was the same as for normal boot - it hunged.
(In reply to comment #6)
> Everything is stock really so selinux is where it is by default.
i.e. enforcing. You're seeing bug 692436.
(In reply to comment #7)
> It's disabled, but it works... It's a SELinux bug
Aha! Thanks for the link. So the problem only appears when SELinux is disabled in /etc/selinux/config but not if "selinux=0" is used.
Problem with SELinux may be related to missing /etc/sysconfig/selinux link
In any case, IMO this problem should be marked as duplicate of 692436 bug.
*** Bug 692602 has been marked as a duplicate of this bug. ***
After upgrading my Fedora 15 Alpha system from systemd 20 to systemd 21, my system stopped booting. Even systemd.unit=rescue.target and systemd.unit=emergency.target don't work; the only way to get in at all is to set init=/bin/sh. My system has SELINUX=disabled in /etc/sysconfig/selinux, and I have the error messages reported in bug #692602:
Failed to load SElinux policy
Failed to set security context system_u:object_r:sysfs_t:s0 for /sys: Invalid argument
Failed to mount /sys/fs/cgroup/systemd: No such file or directory
(In reply to comment #10)
> In any case, IMO this problem should be marked as duplicate of 692436 bug.
I think this is different because this bug deals with the case that SELINUX=disabled but #692436 seems to deal with the case that selinux is enabled.
If we're using this bug to track SELinux's config file not correctly disabling it, I think we can drop F15Beta. We have a different bug covering the /run-causes-fail-to-boot issue.
I can verify the behavior mentioned in comment #12; same problem here.
... and booting with "selinux=0" does work.
I presume this bug is fixed with the new policy 3.9.16-10. Closing.
If you had asked, I would have mentioned that it still occurs with 3.9.16-10, which I mentioned in the higher priority bug, #692436.
Based on developments in bug #692436, it was determined that the failure to boot in this bug is in fact separate from the failure to boot in the other bug. Thus, this bug should be a beta blocker after all.
I disagree with the classification as a blocker, because:
- SELINUX=disabled in /etc/selinux/config is not a default configuration
- an easy workaround is available (add "selinux=0" to boot parameters)
(In reply to comment #20)
> I disagree with the classification as a blocker, because:
> - SELINUX=disabled in /etc/selinux/config is not a default configuration
> - an easy workaround is available (add "selinux=0" to boot parameters)
My response would be:
- Disabling SELinux is not a default configuration, but it seems to be quite common.
- The severity of the bug (complete failure to boot) might make up for the workaround.
But it's not my decision. :)
If some bug is being nominated by anyone as a blocker, it is useful to quote the blocker criteria. For reference, the requirements are listed at
Andrew McNabb, I recommend going through this and quoting the specific requirement that this bug would fail to meet and then the QA team can make the decision. Thanks.
Rahul, if a system fails to boot, then it does not meet beta release requirement 13, 14, 15, 16, 17, 18, 19, 20, or 21, although requirement 18 is arguable because disabling selinux is not default. :) Of course, requirement 13 is the main one:
13. When booting a system installed without a graphical environment, or when using a correct configuration setting to cause an installed system to boot in non-graphical mode, the system should provide a working login prompt without any unintended user intervention when boot is complete, and all virtual consoles intended to provide a working login prompt should do so
A bug is a blocker if any of three criteria are met, one of which reads, "Bug relates to an unmet Beta Release Requirement".
Is that helpful?
systemd-23-1.fc15 has been submitted as an update for Fedora 15.
systemd-23-1 does not fix this bug.
This is what happens when SELinux is disabled using /etc/selinux/config:
- in selinux_setup() systemd calls:
This call fails and sets enforce=0 as expected.
- later systemd asks:
This call returns 1, which is wrong.
The bug is in libselinux in selinux_init_load_policy(). It mount selinuxfs and remembers the mountpoint using set_selinuxmnt(). Later it unmounts selinuxfs, but it does not reset selinux_mnt. is_selinux_enabled() is then confused and takes the non-NULL selinux_mnt as a proof of enabled SELinux.
A fix would be to call fini_selinuxmnt() after umount(SELINUXMNT) in selinux_init_load_policy().
"Based on developments in bug #692436, it was determined that the failure to
boot in this bug is in fact separate from the failure to boot in the other bug.
Thus, this bug should be a beta blocker after all."
This is the important point. There are two possibilities.
1) This bug is 'disabling SELinux via configuration file does not work, it causes the system to (try and) boot with SELinux enabled'.
2) This bug is 'disabling SELinux via configuration file causes the system to inevitably fail to boot'.
If 2), this is likely to be a blocker. If 1), it is unlikely. If the system only fails to boot *because there's some other bug making the system fail to boot if SELinux is enabled*, that bug is the blocker, not this one.
Adam, 2) is correct.
When SELINUX=disabled is used, SELinux gets in fact disabled correctly, but systemd is mislead to believe the contrary and then it gets very sad when the SELinux-related calls are failing. It fails to mount the essential filesystems and stops booting.
*** Bug 693410 has been marked as a duplicate of this bug. ***
Fixed in libselinux-2.0.99-3.fc15
libselinux-2.0.99-4.fc15 has been submitted as an update for Fedora 15.
I have been trying to install my Fedora 15 virtual machine so that I can test this, but right now I'm stuck because bug #693881 is preventing Anaconda from completing an install. In the meantime, would anyone else be able to test the fix in libselinux-2.0.99-4.fc15?
I already did, and filed feedback.
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libselinux-2.0.99-4.fc15'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
I can confirm that libselinux-2.0.99-4.fc15 fixes the problem on x86_64. txs!
Looks fixed for me too.
I can confirm that this is now fixed for me, too. Thanks to everyone who helped.
Discussed during the 2011-04-08 blocker review meeting . AcceptedBlocker for beta. Issue fixed in latest libselinux already included in RC1
Moving to VERIFIED based on test feedback. Thanks all!
libselinux-2.0.99-4.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
I have upgraded my Fedora 14 x86_64 to 15.
I had keeped my old Kernel, and there were many problems, for example "Failed to load SELinux policy." and I obtained only emergency mode.
I installed the following packages that were not present, because I disabled SELinux :
After, I have updated Kernel to latest version :
Now, Fedora 15 boot, but I see on the screen "Failed to load SELinux policy." a short moment.
In the log /var/log/messages I read only :
May 26 08:43:03 kernel: [ 0.001101] SELinux: Initializing.
May 26 08:43:03 kernel: [ 8.885976] SELinux: Disabled at runtime.
set "selinux=0" into kernel args don't change anything.
My /etc/selinux/config contains :
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# mls - Multi Level Security protection.
Maybe an idea ?
(In reply to comment #40)
> I have upgraded my Fedora 14 x86_64 to 15.
> I had keeped my old Kernel, and there were many problems
OK, don't use old kernels.
> After, I have updated Kernel to latest version :
> Now, Fedora 15 boot, but I see on the screen "Failed to load SELinux policy."
> a short moment.
This message is harmless when SELinux is disabled.
If you're seeing any other problems, please file a separate bug.
Thank you, now I am appeased... ;)