Bug 447723
| Summary: | Re-enable SELinux caused Fedora unable to boot | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Eric Springer <erikina> | ||||||
| Component: | selinux-policy | Assignee: | Daniel Walsh <dwalsh> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | urgent | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 9 | CC: | jkubin | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2008-07-02 19:23:47 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Eric Springer
2008-05-21 12:31:58 UTC
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? |