[Dan, I've chosen selinux as the component, but it's probably something else.
You're better placed to say which, and reassign, if needed. Thanks. ]
Description of problem: I have a bare-metal system that runs rawhide with SELinux in enforcing mode, and I update it pretty frequently. Yesterday I noticed that it was failing a test that it normally passed. The cause: SELinux was turned off in spite of my config setting of SELINUX=enforcing, and nothing in grub.conf that would imply enforcing=0. I.e., getenforce reported Disabled, selinuxenabled would exit with status "1". dmesg output suggested that the kernel was not initializing SELinux, while earlier kernels definitely did do that. Here's one failing kernel version for which I have dmesg output:
2.6.31-0.167.rc6.git6.fc12.x86_64. Yesterday I was running this one:
This shows that the kernel did not initialize SELinux:
$ grep -i selinux /tmp/old-dmesg
SELinux: Starting in permissive mode
SELinux: Registering netfilter hooks
At Dan Walsh's suggestion, I rebuilt initrd like this:
mkinitrd -f \
Then I rebooted, waited a few minutes for a relabel, and when it came up, SELinux was once again in enforcing mode.
Version-Release number of selected component (if applicable): kernel 2.6.31-0.174.rc7.git2.fc12.x86_64
How reproducible: hard to reproduce, probably
Steps to Reproduce:
1. enable SELinux enforcing months ago, run "yum upgrade" starting a few kernels ago, and see that SELinux becomes disabled upon reboot into new kernel.
Actual results: SELinux was disabled
Expected results: SELinux remains in Enforcing mode
minutes ago I updated to kernel 2.6.31-0.180.rc7.git4.fc12.x86_64, and rebooted.
When the system came back, I found that SELinux is once again disabled.
getenforce reports "Disabled".
Remove question mark from subject. it's no longer a question.
[warren@newcaprica ~]$ uname -a
Linux newcaprica 2.6.31-0.180.rc7.git4.fc12.x86_64 #1 SMP Wed Aug 26 16:15:07 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
[warren@newcaprica ~]$ getenforce
This isn't happening for me.
FYI, I rebuilt with mkinitrd, as above, rebooted, and now all's well here.
Warren, want to compare /etc settings or installed package sets?
Created attachment 359071 [details]
list of installed packages
please attach the output of
# lsinitrd <working initrd>
Created attachment 359078 [details]
hi Harald, here's that the output of lsinitrd /boot/initrd-generic-2.6.31-0.180.rc7.git4.fc12.x86_64.img (note, this is the rebuilt, working one)
do you have /usr/sbin/load_policy on your system?
chroot /sysroot /usr/sbin/load_policy -i
before it switches to the new root.
Yes, it has that file:
$ lsattr /usr/sbin/load_policy
Could it be that some file it requires is missing?
$ ldd /usr/sbin/load_policy
linux-vdso.so.1 => (0x00007fffb13df000)
libsepol.so.1 => /lib64/libsepol.so.1 (0x00007f8027aa8000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f802788a000)
libc.so.6 => /lib64/libc.so.6 (0x00007f802750a000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f8027306000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f80270e9000)
FYI, the problem is still here, with latest rawhide kernel, mkinitrd, etc:
Rebooting into new kernel turns off SELinux:
$ uname -r; getenforce
Jim, what does "cat /etc/sysconfig/selinux" say ?
As mentioned in the description, SELINUX=enforcing.
Also SELINUXTYPE=targeted, fwiw.
And nothing in grub options explains the difference either.
To work around the problem, I did this:
v=$(uname -r); mkinitrd -f /boot/initrd-generic-$v.img $v
then rebooted. That put it back in enforcing mode.
Can you install a newer rawhide kernel, and then add: rdbreak
To the kernel cmdline, that should give you a shell before
the switchroot takes place, then from that shell do:
chroot /sysroot /usr/sbin/load_policy -i
And see if you get any error messages, after this you can exit the shell and the boot will continue. It would also be good to know if doing this manually fixed
the not being in enforcing mode issue.
Yes, I can install a newer rawhide kernel. Just tell me which.
Then I'll perform those tests.
Any newer kernel will do, I just want you to get an original dracut initrd again,
as you've overwritten it with your mkinitrd -f workaround.
Next time please use a different name with mkinitrd and edit grub.conf to point to the new one, this way its easy to switch between the 2.
Oh, there's no problem, since I made a backup first. But even if I hadn't, it's easy to remove and reinstall. Will reboot and see, shortly.
Rebooted into the rawhide .199 kernel with " rdbreak" suffix on the boot line.
The result was not usable. Here's what I saw:
error: unexpectedly disconnected from boot status daemon
Dropping to debug shell
sh: can't access tty: job control turned off
#usb 3-3: new full speed...
usb 3-3: device not accepting address 5, error -62
...15 lines of usb device stuff...
C-Alt-N didn't do anything.
So I power cycled it.
Did you try pressing enter to get a prompt, maybe the dmesg output overwrote the prompt ?
Also can you try again with:
rdbreak nomodeset 1
Maybe plymouth is getting in the way.
(In reply to comment #21)
> Maybe plymouth is getting in the way.
bummer. it stopped with same symptoms as above.
I tried first simply replacing rhgb with rdbreak,
and then doing s/rhgb.*/rdbreak/
FYI, SELinux is disabled via very latest kernel in rawhide.
"rdshell rdbreak nomodeset 1"
Hi Harald, thanks for the tip.
With that, the 20+ USB lines made the useful info scroll off the top
(yeah, still no serial). But regardless, the console still stopped, and did not respond to any input. Removing nomodeset gave the same output as in #20, but with one additional line:
Break before switch_root
which came just before the "error: unexpectedly disconnected from boot status daemon" line.
Finally, I tried just "rdshell 1", and that did it. I got a shell.
Taking Hans' suggestion from #16, I was going to run this
chroot /sysroot /usr/sbin/load_policy -i
but there is no /sysroot directory.
I can imagine that would cause trouble ;-)
in case it matters, root's shell is /bin/zsh
err... it seems you are past switch_root already.. anyway, I can't reproduce your selinux problem. :-/
so something about rdbreak isn't working. could it be that I have a GPT partition table?
any other hints on how to pursue it?
If I'm the only one affected, I can just forget about it, nuke this system and install an F12 snapshot directly. Up to you.
ok, please install dracut-001-6.gitf5c4374d.fc12 from
on your system and recreate initrd-generic with dracut (like with mkinitrd)
# dracut -f \
done. rebooted into it, and it turned off SELinux, but I suppose that's still to be expected, for me.
BTW, I installed only dracut-001... and to do that, I had to first install dash.
I'm about to reboot into it again, but with rdbreak this time.
I still get a shell via "rdshell 1", and now /sysroot does exist.
But it's empty.
"1" is only for the runlevel in real root.
no "rhgb" and "rdinfo rdbreak rdshell" should really really give you a shell and something in /sysroot ... otherwise you would not be able to boot.
Here is a new version to try..
please also attach the output of
if you boot from this one.
Also note that the shell you are dropped into does not take any <ctrl> commands and there is no <tab> completion.
You might generate the image with the debug module, so that you have a bash instead of dash.
# dracut -a debug /boot/dracut-$(uname -r).img $(uname -r)
rpm -ivh /t/dracut-001-7.git71094bee.fc12.src.rpm
v=$(uname -r); f=/boot/initrd-generic-$v.img; backup $f
dracut -a debug -f $f $v
I'm preparing to reboot into this:
title Fedora (2.6.31-0.204.rc9.fc12.x86_64)
kernel /vmlinuz-2.6.31-0.204.rc9.fc12.x86_64 ro root=UUID=c5e669eb-0b26-4f27-a590-94558a12e9fc rdinfo rdbreak rdshell
rats. same story. I see the prompt (above 20 lines of USB diags),
but keyboard is unresponsive.
I'm using USB kbd and mouse.
Note that the USB lines mentioned in comment #21 are regarding precisely those devices, so maybe they're just a little too late? I also tried with a conventional keyboard. no difference.
dmesg output coming up
Created attachment 360205 [details]
requested dmesg output
Created attachment 360218 [details]
dmesg, after booting into result of dracut-001-7
the selinux part is missing completely.. very strange.
next step.. boot with
"rdshell rdbreak rdinitdebug rdinfo"
and please take a photo of the last pages of the output
ok, this is because load_policy is in /usr/sbin and Jim has a separate /usr partition, which is of course not mounted at that point of time.
*** This bug has been marked as a duplicate of bug 521932 ***
FYI, after many iterations, we (mostly Harald) finally figured out the cause:
I have /usr on a separate partition, and
depended on /usr/sbin/load_policy being availble before /usr was mounted.
cp -a /usr/sbin/load_policy /sbin
That got me past the initial problem.
Further along, I saw some AVCs and boot failed.
rebooting with enforcing=0 got me in.