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): How reproducible: Didn't try 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. Additional info: 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. /etc/selinux/targeted/policy/policy.20 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 posttrigger. Check /etc/selinux/targeted/policy/policy.20 should now exist. You will need to relabel the system. touch /.autorelabel reboot
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 parameters.) 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 above directions. https://www.redhat.com/archives/fedora-devel-list/2005-December/msg00096.html
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 seems premature.
If you boot with enforcing=0 You should be able to boot. Does the file /etc/selinux/targeted/policy/policy.20 exist? Dan
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 policy.20 present. 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: selinux-policy-targeted-2.0.11-1 selinux-policy-targeted-1.27.2-19 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 "selinux-policy-targeted-1.27.2-19".
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 selinux-policy-targeted-2.0.11-1 Anyway, glad that you are able to get into the system now. Did you relabel then reboot your system? touch /.autorelabel reboot 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 expected.
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 their systems. Reference is: https://www.redhat.com/archives/fedora-test-list/2005-December/msg00287.html The only obvious factors are that the system errored out unless relabeling was performed. 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 8. reboot 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 information there. Bug more specific to the problem: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175449
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