Description of problem: Unable to use emergency mode on a freshly installed Fedora 18 if selinux is enabled (which is the default). I get the following errors: Welcome to emergency mode! Type "systemctl default" or ^D to enter default mode. Type "journalctl -b" to view system logs. Type "systemctl reboot" to reboot. Give root password for maintenance (or type Control-D to continue): XXXXXX sulogin: /bin/bash: exec failed: Permission denied sulogin: /bin/sh: exec failed: Permission denied Login inkorrekt Give root password for maintenance (or type Control-D to continue): XXXXXX Version-Release number of selected component (if applicable): dracut-024-18.git20130102.fc18 How reproducible: Always Steps to Reproduce: 1. Install Fedora 18 2. Reboot 3. Enter "emergency" at the boot prompt. Actual results: Unable to login. See above. Expected results: Login Additional info:
This is _not_ in the initramfs. This is already in the real root.
Could you try this in permissive mode ("enforcing=0") and save any avc denial messages found in dmesg?
Created attachment 680456 [details] dmesg after running with enforcing=0
Maybe it is of interest that I started installation of FC18 with selinux=0 as a kernel parameter during PXE booting of FC18 installation?
On your system sulogin runs as abrt_helper_t, /usr/bin/bash is file_t. These labels make no sense. Perform a complete relabel. (In reply to comment #4) > Maybe it is of interest that I started installation of FC18 with selinux=0 > as a kernel parameter during PXE booting of FC18 installation? I guess that's the cause indeed.
Yes, I verified it. I installed again without using selinux=0 during installation. Now I can use emergency, however I get the following message, but still login: Give root password for maintenance (or type Control-D to continue): sulogin: /root: change directory failed: Keine Berechtigung Logge ein mit Heimatverzeichnis = ,,/". bash-4.2# Therefore 2 points remaining: 1. Fix the above message 2. Fix the situation where installing with selinux=0 and getting a broken system. (I use selinux=0 since the introduction of selinux, because I do not like selinux. Until recently, this boot parameter was transfered by anaconda to the installed system which was then disabling selinux from the beginning. This functionality seems to be gone and it only disabled selinux during installation leading to the problems above. Could you detect this situation and give a appropriate message?
(In reply to comment #6) > Yes, I verified it. I installed again without using selinux=0 during > installation. Now I can use emergency, however I get the following message, > but still login: > > Give root password for maintenance > (or type Control-D to continue): > sulogin: /root: change directory failed: Keine Berechtigung > Logge ein mit Heimatverzeichnis = ,,/". > bash-4.2# > > Therefore 2 points remaining: > > 1. Fix the above message > > 2. Fix the situation where installing with selinux=0 and getting a broken > system. > (I use selinux=0 since the introduction of selinux, because I do not like > selinux. Until recently, this boot parameter was transfered by anaconda > to the installed system which was then disabling selinux from the > beginning. > This functionality seems to be gone and it only disabled selinux during > installation leading to the problems above. > Could you detect this situation and give a appropriate message? I agree with Till Bubeck. And I Can confirm this strange bug.
(In reply to comment #7) > > 2. Fix the situation where installing with selinux=0 and getting a broken > > system. > > (I use selinux=0 since the introduction of selinux, because I do not like > > selinux. Until recently, this boot parameter was transfered by anaconda > > to the installed system which was then disabling selinux from the > > beginning. > > This functionality seems to be gone and it only disabled selinux during > > installation leading to the problems above. > > Could you detect this situation and give a appropriate message? > > I agree with Till Bubeck. And I Can confirm this strange bug. Anaconda should IMO either install a working system, or should refuse to install with an explanation.
Or, give back option to disable SELinux to firstboot package.(In reply to comment #8) > (In reply to comment #7) > > > 2. Fix the situation where installing with selinux=0 and getting a broken > > > system. > > > (I use selinux=0 since the introduction of selinux, because I do not like > > > selinux. Until recently, this boot parameter was transfered by anaconda > > > to the installed system which was then disabling selinux from the > > > beginning. > > > This functionality seems to be gone and it only disabled selinux during > > > installation leading to the problems above. > > > Could you detect this situation and give a appropriate message? > > > > I agree with Till Bubeck. And I Can confirm this strange bug. > > Anaconda should IMO either install a working system, or should refuse to > install with an explanation. Or give back option to disable SELinux into firstboot package.
(In reply to comment #9) > > Anaconda should IMO either install a working system, or should refuse to > > install with an explanation. > > Or give back option to disable SELinux into firstboot package. I would prefer a clean solution over a workaround :).
Chris already fixed it upstream. That's why this BZ is in POST state. http://git.fedorahosted.org/cgit/anaconda.git/commit/pyanaconda/bootloader.py?id=f0fc233726e1692898cfacf93318959eb45059a8
(In reply to comment #11) > Chris already fixed it upstream. That's why this BZ is in POST state. > > http://git.fedorahosted.org/cgit/anaconda.git/commit/pyanaconda/bootloader. > py?id=f0fc233726e1692898cfacf93318959eb45059a8 Thanks. Looks easy.