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.
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
4. Enable SElinux
??? Unable to boot up?
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
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).
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]
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?
should fix the context on the /bin/login file.
You can also just
to fix the labeling.
You are running ext3 file systems correct?