Description of problem: I installed system with 'noselinux' anaconda option and when I booted to the installed system selinux is enabled (and runs). Version-Release number of selected component (if applicable): tested with 16.25 (f16 install dvd) because there are no f17 install dvds. How reproducible: allways Steps to Reproduce: 1. boot dvd.iso and press tab in boot menu 2. add option noselinux and press enter 3. install system Actual results: selinux is enabled in installed system Expected results: selinux should be disabled Additional info: when I install with selinux=0 it works fine.
I propose this as final blocker. It meets final criterion "The installed system must run normally if the user chooses to install without SELinux"
This is caused by the loader code that ignores 'noselinux' and doesn't pass it to stage2. Will, could you please make sure this works in the new noloader scheme?
Yeah, the currently proposed patches will make anaconda pick up 'noselinux' and proceed accordingly. See here: https://www.redhat.com/archives/anaconda-devel-list/2012-February/msg00084.html [adds BootArgs.getbool(), which interprets "noARG" as "ARG=0"] https://www.redhat.com/archives/anaconda-devel-list/2012-February/msg00085.html [uses BootArgs.getbool() to set anaconda's 'selinux' flag] We might deprecate this in favor of "selinux=0" someday, though.
Does this work as expected with F17Beta? The code in comment #3 is present there. If not: does it work as expected if you use "selinux=0"?
Discussed at 2012-04-20 blocker review meeting. We don't have any criteria requirements that install without SELinux enabled be possible, and selinux=0 is available anyhow, so this is rejected as a blocker.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
(In reply to Will Woods from comment #4) > Does this work as expected with F17Beta? The code in comment #3 is present > there. > > If not: does it work as expected if you use "selinux=0"? It doesn't, because we're not doing anything with the option once we read it, turns out. Whoops! I think something like this should do the job: https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-April/010264.html
Is there actually a use case that requires this instead of "selinux=0"? I did say we would deprecate this someday... and that was two years ago.
I dunno, but selinux=0 didn't work either. noselinux made it through the command line parser as equivalent to selinux=0, and from there we used it for exactly nothing.
anaconda doesn't, but something else does. IIUC, will's saying "what's the point of this if you can just do selinux=0 both during install and on the booted system?"
(In reply to Adam Williamson from comment #10) > anaconda doesn't, but something else does. IIUC, will's saying "what's the > point of this if you can just do selinux=0 both during install and on the > booted system?" So, maybe, back in the times of yore when this bug was opened, there was a problem in that booting the installer with selinux=0 would translate into selinux being disabled in the installed system, and noselinux did not. The code in comment 3 fixes that issue in that selinux=0 and noselinux are interpreted in the same way. The problem now--and possibly also the problem then--is that neither of them do anything in the context of the installer. The patch I posted propagates selinux=0 or noselinux or any other selinux setting on the kernel command line by writing SELINUX=<whatever> into /etc/config/selinux on the installed system, so that whatever selinux setting was chosen to boot the installer is also used on the installed system. It could also be propagated just copying the boot argument over when installing the bootloader. Both of these are things we can do. It may be time to change the bug description.