Bug 1128073 - rhel-6.6 dracut: SELinux: Could not open policy file <= /etc/selinux/targeted/policy/policy.24
Summary: rhel-6.6 dracut: SELinux: Could not open policy file <= /etc/selinux/targeted...
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: rpm
Version: 6.6
Hardware: Unspecified
OS: Linux
Target Milestone: rc
: ---
Assignee: Packaging Maintenance Team
QA Contact: Milos Malik
Depends On:
TreeView+ depends on / blocked
Reported: 2014-08-08 08:55 UTC by Lubos Kocman
Modified: 2016-01-07 03:03 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-08-31 09:48:18 UTC
Target Upstream Version:

Attachments (Terms of Use)
boot output from console (18.78 KB, text/plain)
2014-08-08 08:55 UTC, Lubos Kocman
no flags Details

Description Lubos Kocman 2014-08-08 08:55:05 UTC
Created attachment 925126 [details]
boot output from console

Description of problem:


I just did clean install of today's nightly RHEL-6.6-20140808.n.0 (Virtualbox)
boot ended up with Kernel panic caused by dracut: SELinux: Could not open policy file <= /etc/selinux/targeted/policy/policy.24

System boots fine with selinux=0

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. install RHEL-6.6-20140808.n.0 (on vbox in my case)
2. make sure system has selinux enabled
3. boot to system after installation
Actual results:

dracut: Loading SELinux policy^M
type=1404 audit(1407487338.592:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295^M
dracut: SELinux: Could not open policy file <= /etc/selinux/targeted/policy/policy.24: No such file or directory /sbin/load_policy: Can't load policy and enforcing mode requested: No such file or directory^M
dracut Warning: Initial SELinux policy load failed.^M
dracut FATAL: Initial SELinux policy load failed. Machine in enforcing mode. To disable selinux, add selinux=0 to the kernel command line.^M
dracut Warning: ^M
dracut Warning: Boot has failed. To debug this issue add "rdshell" to the kernel command line.^M

kernel panic

Expected results:

bootable system

Additional info:

(guest was installed on VirtualBox-4.3-4.3.14_95030_fedora18-1.x86_64 running  on fedora20)

Comment 1 Milos Malik 2014-08-08 09:05:10 UTC
Today I installed the same nightly tree (RHEL-6.6-20140808.n.0) and the same architecture (x86_64) in my KVM via VIrtual Manager and everything went fine. Which variant and which installed method did you use?

 * variant: Server, package set: minimal install, network install via HTTP protocol

Comment 3 Lubos Kocman 2014-08-08 10:11:58 UTC
Server and picked up Basic server installation.

Comment 4 manuel wolfshant 2014-11-12 15:13:54 UTC
I have just triggered the same problem on a system on which I just installed CentOS 6.6/i386.
If I am not mistaken it appears when anaconda tries to install selinux-policy-targeted prior to installing libselinux-utils. In my case I see:
[root@pc70 ~]# grep selinux *log
install.log:Installing libselinux-2.0.94-5.8.el6.i686
install.log:Installing selinux-policy-3.7.19-260.el6.noarch
install.log:Installing selinux-policy-targeted-3.7.19-260.el6.noarch
install.log:/var/tmp/rpm-tmp.ZBc767: line 7: selinuxenabled: command not found
install.log:Installing libselinux-python-2.0.94-5.8.el6.i686                  
install.log:Installing libselinux-utils-2.0.94-5.8.el6.i686     

The result of the above sequence is that the *selinux packages are installed but /etc/selinux/targeted/policy/policy.24 is not created.
rpm -ql selinux-policy-targeted  lists this file but it is ghosted so its presence ( or absence ) can not be verified with rpm -V, one needs to use ls to verify. In my case, the directory /etc/selinux/targeted/policy was completely empty.

The end result is that after reboot the system either boots with selinux disabled (!!! - happens here with kernel-2.6.32-504.el6.x86_64 ) or panics at boot as described at https://bugzilla.redhat.com/show_bug.cgi?id=1128073#c0

I strongly suspect that https://bugzilla.redhat.com/show_bug.cgi?id=731621 describes the same problem and the presence/absence of swap was not the real culprit.

If I am not mistaken the solution is to make sure that selinux-policy-targeted has Requires(pre): libselinux-utils

Comment 5 Milos Malik 2014-11-12 15:54:53 UTC
Very interesting situation. I agree with your analysis, Manuel.

Are we able to re-shuffle the list of packages to be installed? Is it possible that policycoreutils package gets installed after selinux-policy-targeted package?

Comment 6 Lubos Kocman 2014-11-12 17:43:26 UTC
We'll that could be solved by proper dependency settings between rpms. I'm not aware of any other method.

Comment 7 manuel wolfshant 2014-11-13 09:03:01 UTC
This morning I've hit this problem again while installing a different system, with a different kickstart. I've digged a bit deeper and it seems that the ordering is even more complicated. 
In its %postinstall, selinux-policy-targeted does:
if [ $1 -eq 1 ]; then                                                            
. /etc/selinux/config;                                                           
( cd /usr/share/selinux/targeted;
semodule -n -r oracle-port -b base.pp.bz2 -i $packages -s targeted 2>&1 | grep -v "oracle-port";
[ "${SELINUXTYPE}" == "targeted" ] && selinuxenabled && load_policy;
);   restorecon -R /root /var/log /var/run 2> /dev/null
   semodule -n -s targeted -r moilscanner -r mailscanner -r gamin -r audio_entropy -r iscsid -r polkit_auth -r polkit -r rtkit_daemon -r ModemManager -r telepathysofiasip -r passanger -r rgmanager -r aisexec -r corosync -r pacemaker -r amavis -r clamav -r glusterfs 2>/dev/null

 As you can see, the scriptlet relies on the presence of semodule ( a binary provided by policycoreutils )  and selinuxenabled ( provided by libselinux-utils ). Unfortunately the ordering during install does not seem to be guaranteed because in my install.log I see:
[root@pc65 ~]# grep -n "policycore\|selinux" install.log
60:Installing libselinux-2.0.94-5.8.el6.x86_64
641:Installing selinux-policy-3.7.19-260.el6.noarch
673:Installing libselinux-python-2.0.94-5.8.el6.x86_64
893:Installing selinux-policy-targeted-3.7.19-260.el6.noarch
894:/var/tmp/rpm-tmp.1dbDfR: line 7: selinuxenabled: command not found
935:Installing libselinux-utils-2.0.94-5.8.el6.x86_64
972:Installing libselinux-2.0.94-5.8.el6.i686
1058:Installing policycoreutils-2.0.83-19.47.el6_6.1.x86_64

 In addition the problems was worsened ( in my case ) by kernel-504 booting but with selinux disabled (!) leaving to a false feeling of "all is well" while in fact the system was in very bad shape.

Comment 9 Robert Rauchstaedt 2014-11-18 00:02:23 UTC

I also ran into this problem while setup a virtual machine (KVM) via Cobbler/kickstart.

25:Installing libselinux-2.0.94-5.8.el6.x86_64
117:Installing selinux-policy-3.7.19-260.el6.noarch
179:Installing selinux-policy-targeted-3.7.19-260.el6.noarch
180:/var/tmp/rpm-tmp.tc3D1v: line 7: selinuxenabled: command not found
195:Installing libselinux-utils-2.0.94-5.8.el6.x86_64
250:Installing policycoreutils-2.0.83-19.47.el6_6.1.x86_64

I use:
%packages --nobase
for my basic server installation.

Is there a workaround for this issue?

-- Robert

Comment 10 manuel wolfshant 2014-11-18 03:31:58 UTC
Given that by the time the %post part of the kickstart is executed, the needed binary (i.e. semodule ) is in place, until an official fix comes out I've temporarily added

   yum -y reinstall selinux-policy-targeted

to the %post section of my kickstart recipes.
Alternatively you can just rerun the %postinstall scriptlet from this rpm.

Comment 11 Ľuboš Kardoš 2015-04-16 08:27:53 UTC
Is this still reproducible somehow? RHEL-6.6-20140808.n.0 is not available any more. I tried to install RHEL-6.6-20140812.1 and everything works fine for me.

Comment 12 Ľuboš Kardoš 2015-08-31 09:48:18 UTC
Because I didn't get information I requested 3 months ago (comment 11), I am closing this bug. Feel free to reopen this bug but provide requested information.

Comment 13 manuel wolfshant 2016-01-07 01:13:53 UTC
The problem just occurred to a user from the #centos channel while installing the CentOS-6.7 minimal image

Comment 14 Alessandro 2016-01-07 02:12:13 UTC
Hello, I am the user who reported the issue Manuel is talking about in the comment above.

I'm using the RHEL 6.7 x64 binary DVD (downloaded today; from the website it reports the last modified date is "2015-07-22"). I can reproduce the same issue also with CentOS 6.7 too.

My environment is VirtualBox 5.0.12, running on Windows 10 x64 and Mac OSX 10.11.2 x64. The VM has assigned 1 vCPU and 1 GB of RAM.

Also, I'm installing the minimal RHEL 6.7 system, with no extra packages.

If during the installation I use the default partition layout (which uses LVM), the OS installs and then boots correctly.

However, when I try to use a custom partition layout - as I cannot use LVM - the installation succeeds but the OS crashes at boot with the error above. The partition layout that I use is:
- /dev/sda1: /boot 600MB ext4
- /dev/sdb1: / 7.4GB ext4
Both partitions are standard, and the bootloader is installed on /dev/sda. There's no swap partition intentionally. I can get the OS to boot successfully if I use "selinux=0" in Grub; with the default configuration (as freshly installed by Anaconda), however, the OS crashes at boot with the kernel panic above.

Following the steps above will make the bug happen 100% of times.

Aside from the partition layout used, in Anaconda I'm using the default values almost always. Exceptions: en_US locale but Italian keyboard layout, and Etc/UTC as timezone.

Also, please note that a similar configuration with RHEL 7.2 is not giving me any issue.

Comment 15 Alessandro 2016-01-07 02:20:11 UTC
Actually, I just performed another test. It seems that the issue is the lack of a swap partition: if I add a swap partition to my custom layout, the system will boot. However, I must not use swap in my system.

Comment 16 Alessandro 2016-01-07 03:03:13 UTC
Last findings. With 4GB of memory the system boots. I guess my VM was just low on RAM. Apologize for this, it's probably a different bug.

Note You need to log in before you can comment on or make changes to this bug.