Description of problem: After last updates Fedora hangs in boot splash for quite a while (5-10 minutes) creating these boot-messages (on <ESC>) [...] Starting ACPI Event Daemon... Starting LSB: Daemon to access a smart card using PC/SC... Starting Permit User Sessions... Starting LSB: Start up the NFS file locking service failed, see 'systemctl status nfslock.service' for details. Starting LSB: Start and stop the MD software raid monitor failed, see 'systemctl status mdmonitor.service' for details. Starting NetworkManager failed, see 'systemctl NetworkManager.service' for details. Starting ABRT Automated Bug Reporting Tool failed, see 'systemctl status abrtd.service' for details. Starting SYSV: Enable monthly update of Smolt... After that, gdm does not start, but login via tty2-6 is possible (but login/password-prompts are very sluggish). Was not able to start NetworkManager and other services stated above manually via console/systemctl. Rebooting the system after that fails (hangs at Fedora Logo: "Rebooting..."). How reproducible: always Steps to Reproduce: 1. apply newest updates 2. reboot Actual results: described above Expected results: gdm, working NetworkManager etc. Additional info: had a selinux-message after updating rsyslog but ignored it.
Disabling selinux in /etc/selinux/conf makes the system start flawlessly. Now about some log-Files. When attempting to start with selinux "enforcing" (like in the bug report), there are no messages AT ALL in /var/log/messages. Some interesting lines from /var/log/audit/audit.log: type=AVC msg=audit(1300531833.214:35): avc: denied { read } for pid=1168 comm="sendmail" name="hosts" dev=dm-1 ino=528167 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file [...] type=SERVICE_START msg=audit(1300532017.534:40): user pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=': comm="nfslock" exe="/bin/systemd" hostname=? addr=? terminal=? res=failed' type=SERVICE_START msg=audit(1300532017.543:41): user pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=': comm="mdmonitor" exe="/bin/systemd" hostname=? addr=? terminal=? res=failed' type=SERVICE_STOP msg=audit(1300532131.559:42): user pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=': comm="systemd-logger" exe="/bin/systemd" hostname=? addr=? terminal=? res=success' type=SERVICE_START msg=audit(1300532197.547:43): user pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=': comm="NetworkManager" exe="/bin/systemd" hostname=? addr=? terminal=? res=failed' type=SERVICE_START msg=audit(1300532197.566:44): user pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=': comm="abrtd" exe="/bin/systemd" hostname=? addr=? terminal=? res=failed'
file_t is clearly a wrong label for /etc/hosts. Make sure you have initscripts >= 9.27 installed. Then do a full relabel: touch /.autorelabel && reboot That will fix the problem. Also note that when debugging SELinux-related troubles it is better to put it into permissive mode, rather than disabling it completely, because using the filesystem while SELinux is disabled destroys the file labels.
Thanks for your advise! I set SELinux to enforcing and did a full relabel. I saw the status bar of relabeling and everything went without errors. (E.g. now I'm having "system_u:object_r:net_conf_t:s0 /etc/hosts") After relabeling, the system rebooted automatically. But after the reboot I ran into exactly the same errors as stated in my first post (of course except for the hosts-file and sendmail). So this time I set SELinux to permissive (sorry for disabling in the first place, you are right - disabling is kind of useless) and now I can see some interesting output in setroubleshoot! At first, I list only the headers. Some of those errors are known and filed in other bug reports, so maybe you could tell me which ones cause this behaviour: 1. SELinux is preventing /bin/systemd-tty-ask-password-agent from 'read' accesses on the fifo_file 4:3. 2. SELinux is preventing /usr/sbin/NetworkManager from read access on the file NetworkManager.pid. 3. SELinux is preventing /usr/libexec/gdm-session-worker from entrypoint access on the file /usr/bin/gnome-keyring-daemon. 4. SELinux is preventing /usr/libexec/gdm-session-worker from entrypoint access on the file /etc/X11/xinit/Xsession. 5. SELinux is preventing /bin/login from entrypoint access on the file /bin/bash. 6. SELinux is preventing systemd from using the sigchld access on a process. 7. SELinux is preventing /sbin/unix_chkpwd from sendto access on the unix_dgram_socket /dev/log. 8. SELinux is preventing /bin/login from sendto access on the unix_dgram_socket /dev/log. 9. SELinux is preventing /sbin/rsyslogd from using the sys_nice capability. 10. SELinux is preventing /usr/bin/canberra-gtk-play from getattr access on the sock_file /tmp/at-spi2/socket-1418-1804289383. 11. SELinux is preventing /usr/bin/canberra-gtk-play from unlink access on the sock_file socket-1418-1804289383. And please consider, that I just did a full relabel one boot ago!
I'm sorry, I got some of the selinux-output wrong, because some of it was from after the relabelling. So please ignore 1-8. Interestingly enough, I'm getting different error messages every time I reboot. I did another full relabel and now I'm getting these errors: 1. SELinux is preventing /sbin/rsyslogd from using the sys_nice capability. 2. SELinux is preventing /usr/libexec/gnome-settings-daemon from getattr access on the sock_file /tmp/at-spi2/socket-1338-805750846. 3. SELinux is preventing /usr/libexec/gnome-settings-daemon from unlink access on the sock_file socket-1338-805750846. (Please note, that the first one is mentioned here: https://bugzilla.redhat.com/show_bug.cgi?id=689089)
Had another try with "enforcing", but still the same outcome. It might be worth mentioning that it hangs really long (>5min) when "Starting Permit User Sessions...". After the last reboot I had nothing but the rsyslogd-problem (!)
I just figured out that "audit2allow" with the rsyslogd-thing solved my problem. I'm still getting the sock_file-errors with some gnome-processes like gnome-settings-daemon and metacity... But this bug is closed now. Thanks for your support Michal :-) *** This bug has been marked as a duplicate of bug 689089 ***