RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1101967 - RHEL6.4 build panic after dracut FATAL: Initial SELinux policy load failed
Summary: RHEL6.4 build panic after dracut FATAL: Initial SELinux policy load failed
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.4
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-28 09:18 UTC by Vitaly Isaev
Modified: 2019-07-11 07:59 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 856332
Environment:
Last Closed: 2015-02-25 12:40:14 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
output of ausearch (see #c10) (5.27 KB, text/plain)
2014-06-03 15:09 UTC, Vitaly Isaev 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 856332 0 unspecified CLOSED RHEL6.4 build panic after dracut FATAL: Initial SELinux policy load failed 2021-02-22 00:41:40 UTC

Description Vitaly Isaev 2014-05-28 09:18:32 UTC 
+++ This bug was initially created as a clone of Bug #856332 +++

Description of problem:

The first boot of the virtual machine (inside RHEV 3.1 environment) with just installed RHEL 6.4 Desktop x86_64 fails due to the kernel panic:
  
dracut Warning: dracut: FATAL: Initial SELinux policy load failed. Machine in enforcing mode. To disable selinux, add selinux=0 to the kernel command line. 
dracut Warning: dracut: Refusing to continue 
Kernel panic - not syncing: Attempted to kill init! 


Version-Release number of selected component (if applicable):
RHEL 6.4 Desktop x86_64

How reproducible:
100% reproducible under the following conditions:
1. Swap partition is removed from the VM's filesystem table at the time of partition configuring (we really need to do it due to security reasons);
2. VM's RAM is not more than 1024 MB; 

Steps to Reproduce:
1. Deploy RHEV 3.1 virtualization environment (rhevm-allinone-plugin is OK);
2. Create VM with the mentioned parameters;
3. Install RHEV 6.4 Desktop x86_64 to the VM;
4. Wait until the machine will attempt to boot the first time.
  
Actual results:

Kernel panic

Expected results:

Boot OS without panic

Additional info:

(exactly the same as in bug #856332)

--- Additional comment from Scott Poore on 2012-09-18 13:49:51 EDT ---

Any word on this one?

Here's a little more info from the failure I saw:

Kernel panic - not syncing: Attempted to kill init! 
Pid: 1, comm: init Not tainted 2.6.32-306.el6.x86_64 #1 
Call Trace: 
 [<ffffffff81503dff>] ? panic+0xa0/0x168 
 [<ffffffff81070eb2>] ? do_exit+0x862/0x870 
 [<ffffffff8117f365>] ? fput+0x25/0x30 
 [<ffffffff81070f18>] ? do_group_exit+0x58/0xd0 
 [<ffffffff81070fa7>] ? sys_exit_group+0x17/0x20 
 [<ffffffff8100b0f2>] ? system_call_fastpath+0x16/0x1b 

Also we confirm the issues described in (http://dougbunger.blogspot.ru/2012/12/dracut-fatal-initial-selinux-policy.html):
file /etc/selinux/targeted/policy/policy.24 is absent on fresh VM's filesystem when we tried to access them from rescue iso boot
Comment 2 Miroslav Grepl 2014-05-30 07:28:59 UTC 
Just to be sure, is the selinux-policy installed?
Comment 3 Vitaly Isaev 2014-05-30 08:29:06 UTC 
(In reply to Miroslav Grepl from comment #2)
> Just to be sure, is the selinux-policy installed?

Hello, Miroslav, I don't know how to check this since VM is refusing to boot
Comment 4 Daniel Walsh 2014-05-30 21:28:36 UTC 
Have you tried to boot with enforcing=0 or selinux=0?
Comment 5 Miroslav Grepl 2014-06-02 05:54:05 UTC 
I believe you will need to boot with selinux=0 because it looks there is no selinux-policy pkg.

But yes, could you try to boot with enforcing=0 or selinux=0?
Comment 6 Vitaly Isaev 2014-06-02 09:31:37 UTC 
I have set up enforcing=0 in GRUB kernel parameters. The system has successfully booted at first time, and it seems like everything in its place:

[root@localhost ~]# rpm -qa | grep selinux
libselinux-utils-2.0.94-5.3.el6.1.x86_64
selinux-policy-3.7.19-195.el6.5.noarch
selinux-policy-targeted-3.7.19-195.el6.5.noarch
libselinux-python-2.0.94-5.3.el6.1.x86_64
libselinux-2.0.94-5.3.el6.1.i686
libselinux-2.0.94-5.3.el6.1.x86_64
Comment 7 Miroslav Grepl 2014-06-03 08:21:53 UTC 
And if you execute

# yum reinstall selinux-policy-targeted

does it blow up?
Comment 8 Vitaly Isaev 2014-06-03 09:47:37 UTC 
(In reply to Miroslav Grepl from comment #7)
> And if you execute
> 
> # yum reinstall selinux-policy-targeted
> 
> does it blow up?

Miroslav, reinstallation of that package brought my guest OS to life. The first booting process launched the relabeling of the file system. One more reboot and I saw the login screen. 

[root@localhost ~]# getenforce
Enforcing
Comment 9 Miroslav Grepl 2014-06-03 14:44:55 UTC 
Ok, it looks the policy is not correctly installed and the reinstall fix it. 

Could you boot with

enforcing=0

to see if you get AVC msgs?
Comment 10 Vitaly Isaev 2014-06-03 14:51:54 UTC 
(In reply to Miroslav Grepl from comment #9)
> Ok, it looks the policy is not correctly installed and the reinstall fix it. 
> 
> Could you boot with
> 
> enforcing=0
> 
> to see if you get AVC msgs?

Do you suggest me to do it machine with broken or reinstalled package? 
Where should I look for AVC? /var/log/messages or /var/log/audit?
Comment 11 Miroslav Grepl 2014-06-03 14:59:46 UTC 
With reinstalled package.

# ausearch -m avc -ts recent

after boot in permissive mode.
Comment 12 Vitaly Isaev 2014-06-03 15:08:12 UTC 
(In reply to Miroslav Grepl from comment #11)

> # ausearch -m avc -ts recent

Output is attached as avc.log
Comment 13 Vitaly Isaev 2014-06-03 15:09:05 UTC 
Created attachment 901821 [details]
output of ausearch (see #c10)
Comment 14 Miroslav Grepl 2014-06-09 13:00:45 UTC 
Do you log in as root in X?
Comment 15 Vitaly Isaev 2014-06-09 14:52:56 UTC 
(In reply to Miroslav Grepl from comment #14)
> Do you log in as root in X?

I guess I did (it was a long time ago..) Do you want me to log in as unprivileged user?
Comment 16 Miroslav Grepl 2014-06-24 15:29:33 UTC 
(In reply to Vitaly Isaev from comment #15)
> (In reply to Miroslav Grepl from comment #14)
> > Do you log in as root in X?
> 
> I guess I did (it was a long time ago..) Do you want me to log in as
> unprivileged user?

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