Red Hat Bugzilla – Bug 447723
Re-enable SELinux caused Fedora unable to boot
Last modified: 2008-07-02 15:23:47 EDT
Description of problem: While trying to diagnose a network problem, I disabled SELinux and firewall. (Just so that I wouldn't have to worry about them getting in the way). The network problem ended up being completely irrelevant to SELinux so I re-enabled it. When re-enabling SELinux - I got a warning that it would take a while to "re-label?" some files or something. After rebooting the machine, I found it stalled at the "enable HAL:" stage. So I figured this was what the warning box was about. I decided to leave the computer for a few hours to do its own thing. Coming back, there was a bunch of errors on screen (still in terminal) and the computer seemed locked up. I "control alt deleted" and reset the computer. On reseting, it didn't stall at the "HAL" stage. But spits out a tonne of errors. How reproducible: Not sure. Perhaps a few people should try this with SELinux. I also never re-enabled the firewall after disabling it if that made a difference. Steps to Reproduce: 1. Disable firewall 2. Disable SELinux 3. Reboot 4. Enable SElinux 5. Reboot ??? Unable to boot up? Additional info: I am using the Fedora 9, whole partition encryption. Until I reinstall Fedora (or hopefully fix it). I will be using Ubuntu on another partition. If someone can tell me how to mount the encrypted fedora partition from Ubuntu, I'll be happy to provide log files etc. I chose "Fedora-release" as the component. I'm not sure if this is correct or not.
Throwing at selinux-policy as a closer target to the problem.
Did you get a lot of AVC messages in /var/log/audit/audit.log
Daniel, unfortunately I'm unable to to check. As I cannot boot up, and I'm not quite sure how to manually mount a Fedora encrypted partition from another (Ubuntu) partition.
If you boot with the boot flag enforcing=0 SELinux should not prevent you from booting. If SELinux is the problem.
Thank you Daniel. SELinux was indeed stopping me booting. enforcing=0 allowed me to boot up properly (Although, it did give an error about sda5 not being found during the fstab stage .. which I'm not worried about).
Created attachment 306316 [details] A copy of /var/log/audit/audit.log
After boot with kernel parameter "enforcing=0" try to run: # fixfiles relabel After reboot the problem should be fixed.
This looks like the machine did not try to relabel when you turned SELinux back into enforcing mode. I will have to experiment with this. This the machine stall on boot and tell you it was relabeling? Did it put out several lines of "*"s?
Josef, I tried "fixfiles relabel" but it spat out some errors. I saved them on my PC, but unfortunately I don't have access to that right now. Daniel, the machine stalled that the "Starting HAL:" stage. I never saw several lines of *s, although I left the computer do its own thing for a few hours. When I get home, I'll post the errors I got from "#fixfiles relabel".
[root@localhost ~]# fixfiles relabel Files in the /tmp directory may be labeled incorrectly, this command can remove all files in /tmp. If you choose to remove files from /tmp, a reboot will be required after completion. Do you wish to clean out the /tmp directory [N]? y Cleaning out /tmp /sbin/setfiles: unable to stat file /home/eric/.gvfs: Permission denied /sbin/setfiles: error while labeling /: Permission denied /sbin/setfiles: error while labeling /boot: Permission denied /sbin/setfiles: error while labeling /media/disk-1: No such file or directory
After this, can you reboot in enforcing mode?
No, I can not. It gets to the normal console login (Where it says something like: Fedora 9 (Sulfur). Login: That will flash extremely rapidly, and not allow me to login. Thanks for all your help guys. You're so helpful it's looking like a support thread. Which I don't need. I primarily use Fedora 8, on a completely different computer. My motivations are reporting what seems to be a very serious bug. So if there is anything I can do, to help you find the problem (or reproduce it), I'm more than happy - but I don't actually need any assistance.
Well boot in permissive mode and then attach your /var/log/audit/audit.log boot flag enforcing=0 will allow you to boot in permissive mode.
Created attachment 306774 [details] /var/log/audit/audit.log
For some reason getty is not transitioning to login when it executes the program. How is /bin/login labeled? ls -lZ /bin/login -rwxr-xr-x root root system_u:object_r:login_exec_t:s0 /bin/login
I've noticed no one seems to be able to reproduce the bug. Perhaps it's not at severe as I previously believed? When I boot in Fedora to get your files I'm using "enforcing=0 3". As somehow, I managed to blow my graphics card - and the current Xorg setting doesn't like me much (and Xorg -configure generates another bad xorg.conf file ... but that's a completely different issue). Anyway, this is how /bin/login is labeled: #ls -lZ /bin/login -rwxr-xr-x root root system_u:object_r:file_t:s0 /bin/login
The problem is your system is mislabeled. Did you run fixfiles restore? restorecon /bin/login should fix the context on the /bin/login file. You can also just touch /.autorelabel reboot to fix the labeling. You are running ext3 file systems correct?