Red Hat Bugzilla – Bug 174919
Kernel panic after updating on reboot
Last modified: 2007-11-30 17:11:18 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051018 Fedora/1.7.12-2
Description of problem:
After performing updates from december 2nd and then rebooting, my system would not boot into any runlevel without going into a kernel panic (I tried runlevel 1,3 and 5).
The halt was around the synaptics driver as the previous successful step before the system halted. I tried booting with the previous working kernel with the same kernel panic results.
To get my computer to boot, I had to add selinux=0 to the kernel parameters and then change to runlevel 1 from runlevel 5 after a successful boot. I then ran fixfiles relabel from rulevel 1 and rebooted. The boot was successful but went into relabel the system anyway, which then allowed seemingly normal actions for the computer.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Update from a mirror with programs for December 2nd rawhide
2. start your computer when you decide to use it on the next day
3. notice the kernel panics after loading the synaptics device
4. try to boot with previous working kernel
5. try to boot into different runlevels
6. try to boot with selinux=0 as boot parameter
7. run shutdown 0 from a root shell while in runlevel 5
8. run fixfiles relabel
9. reboot after relabelng completed
Actual Results: some updates would not apply. Installed what did not fail a yum install.
Used computer until done on dec 2nd. Booted and noticed a kernel panic on dec 3rd. rebooted trying previously working kernel. kernel panic received as the newer kernel panicked. Kernel panicked when trying to boot into different runlevels also.
Booting with selinux allowed computer to boot into runlevel 5 with normal program interaction.
7. successfully dropped into maintenence shell
8. computer booted successfully without changing boot parameters from the norm.
Expected Results: Either the computer booted into a mode that would relabel the filesystem and preventing a kernel panic or would boot without any troubles or kernel panic.
I did not try booting with autorelabel as a kernel parameter. I thought of it after the fact. I did run touch /.autorelabel before rebooting with selinux disabled. A kernel panic was received and an additional relabeling of the filesystem happened on reboot. this doubled the time for relabeling or at least ran a second time through relabeling.
I encountered kernel panics after updating from the FC5test1
selinux-policy-targeted version 1.27.2 as well to the new major
release version 2.0.7 as well as to 2.0.8 upon reinstall of the
system and updating to the latter. In both cases, a kernel panic
occurs upon reboot regardless of the kernel version used.
The last message is:
Kernel panic - not syncing: Attempted to kill init!
Problem is policy update accidently removed policy file.
selinux-policy-targeted-2.0.8-1 should fix the problem. To get back into the
machine you can boot with enforcing=0 or selinux=0.
To recreate the policy you can execute
semodule -b /usr/share/selinux/targeted/base.pp
Updating to selinux-policy-targeted-2.0.8-1 should execute this command in a
Check /etc/selinux/targeted/policy/policy.20 should now exist. You will need to
relabel the system.
Thanks! I have selinux-policy-targeted-2.0.8-1 installed currently and did not
know previously about the semodule command or that the policy was never created
leaving me an unbootable system when booted the next day. (With normal kernel
Asking a question on fedora-test-list gave me a reply that the below problem was
addressed on the fedora-development list. The posting reference contained
basically what you stated above.
Closing the bug report in about a week would be fine. People effected will
either have reinstalled without having the problem or worked through it with the
The new package "selinux-policy-targeted-2.0.8-1" did not solve the issue
for me. After encountering kernel panics after an update to version
2.0.7 and reinstalling FC5 test1 from scratch, I updated directly to
version 2.0.8-1. This led to the identical "Kernel panic - not syncing:
Attempted to kill init!" error.
I had pointed this out already in my last comment. Closing the bug thus
If you boot with enforcing=0
You should be able to boot.
Does the file
Reopening this bug since a reinstalation of FC5T1 and then upgrading with
version 2.0.8-1 still seems to have the issue with a halt at init without a
I assume that as grub was loading, a key was pressed, other than enter to show
the grub memnu.
as a kernel is highlighted, the letter 'a' was pressed to append information to
the boot parameter line.
The text rhgb quiet was removed from the kernel boot parameters line, then a
space followed by selinux=0 was added to boot without selinux active. Adding
either the word single after selinux=0 would put you into single user mode where
running 'fixfiles relabel' or 'semodule -b /usr/share/selinux/targeted/base.pp'
followed by 'touch /.autorelabel' and then a reboot of the computer was performed.
Also, adding the full version of rpm that was used would clarify which package
was used. I thought there might have been a version 2.0.8 used and did not
realize you were having trouble with version 2.0.8-1. sorry for closing bug if
not resolved yet.
After today's update to version 2.0.11-1, I had the same problem as
before - kernel panic. After rebooting the system with "enforcing=0",
it turned out, that "/etc/selinux/targeted/policy/policy.20" was
missing. An "rpm -q selinux-policy-targeted" issued two packages:
Updates got installed by means of "up2date". Reinstalling the package
via "rpm -Uhv --force selinux-policy-targeted-2.0.11-1.noarch.rpm"
removed the precursor RPM from the RPM data base. And "policy.20" got
created again. Interestingly, "rpm -qf "/etc/selinux/targeted/policy/
policy.20" yields "file /etc/selinux/targeted/policy/policy.20 is not
owned by any package" whereas before, the answer simply was
I cut and pasted your command above and ended up with a > prompt. I removed the
" before rpm and after policy.20. The " before /etc caused the > prompt.
Anyway, I removed the " before /etc and have the below output.
rpm -qf /etc/selinux/targeted/policy/policy.20
Anyway, glad that you are able to get into the system now. Did you relabel then
reboot your system?
wait for relabeling to complete, then see if things are normal with the latest
policy version installed. If system boots without failure.
The " was meant to serve as a delimiter and - of course - not part of
the command itself.
After reinstalling "selinux-policy-targeted-2.0.11-1" by means of
"rpm", there was no need to do whatsoever, in fact as one would expect.
So this bug is now fixed.
More or less: it is still not clear, why the update did not
get installed properly. I recall that "selinux-policy-targeted"
appeared on the same list as the kernel packages when running
"up2date" before reaching the list containing the remaining
"ordinary" packages. In the kernel case, it is possible to have
multiple versions installed. In the case of "selinux-policy-targeted"
this is certainly not wanted. Maybe a bug in the spec file
which prevents the old package to get uninstalled correctly
or rather a bug in "yum/up2date"? It seems that after
installing the new package, the old one got removed including
the newly created "policy.20" because it was labeled as part of
the old package (see above) whereas "policy.20" is not contained
in the new package anymore. This is not uncommon for config files
which get created by some particular package.
There was a bug in policy that did not rebuild the policy in the correct place,
so this left the system without policy. When people booted without selinux enabled,
selinux=0 or enforcing=0, the next policy update failed because of a
policycoreutils problem that did not update on non selinux boxes...
Both of these problems have been fixed.
I have just performed a fresh install from the rawhide tree. However,
I encounter exactly the same kernel panic as before. Normal boot via
"grub" without modifying the default kernel options. File "policy.20"
is missing upon install. Directory "/etc/selinux/targeted/policy" is
empty. The only remedy is to reboot with "enforcing=0", reinstall
"selinux-policy-targeted-2.0.11-1". This creates the missing policy
file. Upon reboot, the filesystem does not get relabeled automatically.
The corresponding message issued, but the process is skipped immediately.
Instead, plenty of warnings about unlabeled files are issued.
Touching /.autorelabel and rebooting the system leads to a correct
relabeling of the filesystem. Hereafter, operation proceeds as
Someone tried a fresh instalation via ftp of rawhide and encountered the same
problem symptoms and had relatively the same resolutions for this bug to infest
The only obvious factors are that the system errored out unless relabeling was
Problem: Anaconda, yum, post intallation scripts, SELinux program?
Still not fixed in "selinux-policy-targeted-2.1.2-1". A fresh install from
the rawhide tree leads to the already familiar kernel panic.
Try installing with selinux=0 given when system is booted when upgrading from an
FC5 T1 disc installation. The reason that I suggest this approach is that
selinux-policy-targeted does not install because of SELinux policy. (ironic, I
know, permissions for %pre and %post fail on scripts)
Install from discs:
1. Install FC5T1 regularly or with selinux=0 as a boot option.
2. Update your system when booted with selinux=0 as your boot option.
3. Reboot your system
4. If system fails to boot, reboot with selinux=0
5. CTL-ALT-F(1 thru 5, 1 preferred) to a terminal and login as root
6. 'shutdown 0' to drop your system into maintenence mode
7. 'fixfiles relabel' - wait until your system is relabeled
9. see if your system operates normally.
For ftp installs:
issue selinux=0 as a boot option, then follow steps 4 through 9.
I opened a bug more specific to the post and pre script failures on the below
link. If you see it is more in line with the problem experienced, enter
Bug more specific to the problem:
I did not carry out any update. It was an FTP install from scratch based on
the 12/10/2005 "boot.iso" image.
Since the latest SELinux keeps me from using browser plugins and other 3rd
party shared libraries (they seem to want to execute in the stack area),
I have reverted my system back to FC4. I might try again when FC5 test 2 is
out. Thanks for now.
Well then, it seems that the problem after the policy was corrected is now
related to the anaconda installation environment. Both reporters had this happen
after ftp upgrades from rawhide. Myself the boot problem was fixed after a
relabeling of the system on dec 2nd. The additional problem with post and pre
failures was there after relabeling seems fixed also.
fixed in selinux-policy-targeted-2.1.6-19