Hide Forgot
A previously-working F16 install stopped booting to GDM after I brought it up to date on the evening of October 14th (updates-testing is enabled). Later updates have not helped. Normal boot begins normally, with the Fedora logo showing. The screen then shifts to text mode and the boot hangs. Booting to recovery mode works fine. Upon typing ^d or exit in single user mode, I get the same hang. I added "selinux=0" to the kernel command line and the system booted normally. At the next boot I had the system perform an SELinux relabeling to see if that would fix the problem. Unfortunately it did not, and for the moment I am stuck booting with SELinux disabled. Let me know which logs are needed for diagnostic purposes and I will post them. I don't know if I've targeted the bug correctly... sorry about that.
Could you try to boot in permissive mode using enforcing=0 to the kernel command line and then add me outputs of # dmesg |grep avc # ausearch -m avc -ts recent
I rebooted with enforcing=0 and the system performed a relabel (I did not request one), rebooted, then came up normally. # dmesg | head -n4 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.1.0-0.rc9.git0.0.fc16.x86_64 (mockbuild.fedoraproject.org) (gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC) ) #1 SMP Wed Oct 5 15:30:54 UTC 2011 [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.1.0-0.rc9.git0.0.fc16.x86_64 root=UUID=cba1ffde-649b-44ed-9d44-fc31ffa3061e ro quiet rhgb enforcing=0 # dmesg |grep avc [ 6.694085] dbus-daemon[994]: dbus[994]: avc: netlink poll: error 4 [ 6.694139] dbus[994]: avc: netlink poll: error 4 # ausearch -m avc -ts recent <no matches>
When you boot selinux=0 the system turns on the autorelabel itself.
Why was this bug closed? The problem has not been resolved or explained. The system still only finishes booting when selinux=0 or enforcing=0. It will not boot in enforcing mode. Reopened.
Ok, after booting with enforcing=0, what AVC's are you seeing?
Gabe, you booted in the permissive mode and you were not seeing AVC msgs (from your comment #2)
Miroslav: That's true, but the fact is that the system only finishes booting with selinux disabled or in permissive mode. So, by default with no kernel parameters, the system does not manage to get to a graphical UI. This began last Friday. Daniel: You saw the (lack of) AVC's above. Just the dbus messages. What else should I look for? I'm a bit stumped myself.
Well you can turn off dontaudit rules and see if there are rules avc's about gdm. # semodule -DB Then boot it in enforcing=0. attach the output of ausearch -m avc -ts recent compressed. # semodule -B Will turn the dontaudit rules back on. You could also remove quiet and rhgb from the boot like in enforcing mode to see where the boot is hanging.
Created attachment 529431 [details] output of `ausearch -m avc -ts recent`, enforcing=0
Created attachment 529432 [details] kernel output from boot, enforcing=0
I have attached the requested output as well as dmesg output for a successful boot with enforcing=0. When booting in enforcing mode, the hang occurs immediately after the network comes up. Last message on the console is: 8.863361 ADDRCONF(NETDEV_CHANGE): p4p1: link becomes ready I don't see much else of interest in the dmesg, except for the unrelated audispd queue full spam I keep getting these days.
Gabe, I am not sure what causes your issue. Could you try to these two steps # grep -v -E "unix_stream_socket|process" dmesg.txt |audit2allow -M mypol # semodule -i mypol If you won't be able boot in enforcing mode then try # grep -v -E "process|unix_stream_socket|shadow|setroubleshootd" ausearch.txt |audit2allow mypol # semodule -i mypol Also maybe Dan will have an idea.
Miroslav, # grep -v -E "unix_stream_socket|process" dmesg.txt |audit2allow -M mypol # semodule -i mypol ...had no effect. Same hang, same place. # grep -v -E "process|unix_stream_socket|shadow|setroubleshootd" ausearch.txt |audit2allow mypol # semodule -i mypol ...same hang, but new messages on the console right at the moment of the hang: systemd-readahead-collect[454]: fstat(/etc/audit/auditd.conf) failed: Permission denied systemd-readahead-collect[454]: fstat(/var/log/audit/audit.log) failed: Permission denied systemd-readahead-collect[454]: fstat(/etc/audit/auditd.rules) failed: Permission denied
After the latest kernel and selinux policy updates, I still can't boot without either disabling SELinux or setting it to permissive mode.
When you boot in permissive mode and login, what does id -Z Show? If you boot in enforcing mode, does the boot just freeze or are you unable to login?
Daniel, With enforcing=0: # id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 As of now boot hangs right after the network interface comes up. Last output is reliably some readahead permissions errors (see comment 13) and the "interface becomes ready" message (comment 11). I can switch to other TTYs but login prompts don't appear. X never even tries to start.
If you boot to runlevel 3 does it work in enforcing mode? Do you have nvidia drivers installed? I have not heard about anyone else having this problem. You could put gdm and xserver into permissive mode to see if this helps # semanage permissive -a xdm_t # semanage permissive -a xserver_t Another option would be to remove the selinux install policy and reinstall it. # rm -rf /etc/selinux/targeted # yum reinstall selinux-policy-targeted # restorecon -R -v /etc/selinux Then reboot in enforcing mode to see if this changes anything.
Yes, runlevel 3 works fine in enforcing mode. As soon as I try to enter runlevel 5 though, I get the same hang. Putting the gdm and xserver into permissive mode had no effect. Reinstalling the selinux policy had no effect. Is systemd-readahead-collect restricted by selinux policy? Since that is throwing permission denied errors just before the hang (comment 13), maybe unrestricting it would allow boot to continue.
It could be. semanage permissive -a readahead_t
...and no, that didn't help. Same hang. This isn't a huge deal to me at the moment since I will be reinstalling once F16 is released. In the meantime I can run in permissive mode. If you have any further questions or ideas, please ping me. I will pick this up again after a clean install. I'm quite confused as to what could be causing this.
Is this working for you with the released version if not reopen.