| Summary: | non-graceful package update on selinux disabled system. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Anton Arapov <anton> |
| Component: | selinux-policy-targeted | Assignee: | Miroslav Grepl <mgrepl> |
| Status: | CLOSED WONTFIX | QA Contact: | Ben Levenson <benl> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | dracut-maint, dwalsh, harald, jerry.lumpkins, jonathan, michal, nobody |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-02-13 18:48:57 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Anton Arapov
2011-10-20 09:07:16 UTC
Why would you want to install SELinux pkgs with disabled SELinux? And why would you want to disable SELinux :(. :-) That's not a WHY questions. freshly installed fedora has the package -> turn the selinux to off -> reboot -> yum update a system -> you'll get this message. you can add your WHYs instead of load_policy: Can't load policy: No such file or directory. So that user who hit this will try to answer himself, or even better add demotivation message there. :-) Strange it should not be doing this on a system with SELinux disabled. What does your /etc/selinux/config look like? You know, I'm not going to respond directly to the idiot that that asked the question why one would want to install SELinux with disable SELinux because I can't think of anything civil that would make sense to say to them. What I would like to know is why there is documentation on the fedora website that clearly indicates how to disable selinux, and the result of that is a machine that won't boot. Jerry there is no need for that in a bugzilla. Miroslav happens to be the maintainer of selinux-policy and one of the hardest workers on the Fedora team. He clearly was talking tongue in cheek, notice the ":)" This bugzilla does not talk about an issue where disabling SELinux will cause a machine to not boot. The avc is just showing that there is a bug in the update procedure that attempted to load policy on a disabled kernel. If you believe you have a machine that will not boot because SELinux is disabled, please open a new bugzilla and we will look into it. But please be civil. I am thinking we should not be executing this code anymore, since systemd now takes care of this? I am guessing the selinuxenabled is failing because we do not have /sys/fs/selinux yet. Hi, Sorry for the lack of civility. It won't happen again. I don't know if I should open a new bug, or just respond to this one... I changed the value in /etc/selinux/config from SELINUX=permissive to SELINUX=disabled, then rebooted. The result was a repeated hang during boot. Until I booted from a cd, and hand edited the value back to permissive, the machine would not boot. This is a clean install of fedora 16 64bit with all updates to that day installed. The date would have been the same day as my last comment. The machine architecture is as follows: Asus P5K motherboard Intel Core 2 Quad 2.66 8 GB ram 30 GB SSD for boot and system 2 - 1TB drives mirrored with LVM for /home I'm using the KDE window manager. The original install was from the KDE spin of the live 64bit CD. I've been running Fedora since Core 1, and used Redhat prior to that. I take the hard work done by the open source community very seriously, and applaud the diligence of all. I haven't tested this since fixing the problem myself. I have applied all updates through today. If there would be any value in me resetting the value to disabled, and seeing if the issue still exists, I will do that. Regards, Jerry Lumpkins If you execute mv /usr/share/dracut/modules.d/98selinux/selinux-loadpolicy.sh /root And set to disabled, does the problem go away? (In reply to comment #8) > If you execute > mv /usr/share/dracut/modules.d/98selinux/selinux-loadpolicy.sh /root > And set to disabled, does the problem go away? selinux handling has moved from dracut to systemd in F16 Right so why are we executing this script? (In reply to comment #10) > Right so why are we executing this script? we do not.. what makes you think we do? Good question, I guess it is not involved. I just am trying to figure why it is hanging. I saw the script was still there and assumed it might be hitting it. anton if you boot with the boot command selinux=0 Does it hang? *** Bug 759898 has been marked as a duplicate of this bug. *** This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |