Bug 174919

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