Bug 185603 - Boot panics with no useful diagnostics if selinux is misconfigured
Boot panics with no useful diagnostics if selinux is misconfigured
Product: Fedora
Classification: Fedora
Component: sysvinit (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Bill Nottingham
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2006-03-15 20:59 EST by Ben
Modified: 2014-03-16 22:58 EDT (History)
1 user (show)

See Also:
Fixed In Version: 2.86-10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-10 13:43:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Bootlog of domU (4.39 KB, text/plain)
2006-03-15 20:59 EST, Ben
no flags Details

  None (edit)
Description Ben 2006-03-15 20:59:53 EST
Description of problem:

After installing a domU, I logged into it, disabled SELinux, and rebooted it. Of
course, it didn't come back, but after running xm create, it does begin boot.
However, it never let me log in, so I attached a console to it and saw that it
had crashed on boot. I can no longer seem to boot it, regardless of if I create
the domU with a console attached, or attach the console later.

Version-Release number of selected component (if applicable):

This was using all rawhide components current on the morning of 3/15/06.
However, I did hack xenguest-install.py to let me specify a seperate volume for
a swap file. I would like to blame this, but if that was the case, then it seems
like the domU should never have worked after install, when in fact it worked once.

How reproducible:


Additional info:

The full log is attached, but here's the money shot. The stack trace is always
the same.

EXT3-fs: mounted filesystem with ordered data mode.
Setting up other filesystems.
Setting up new root fs
no fstab.sys, mounting internal defaults
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
Kernel panic - not syncing: Attempted to kill init!

Call Trace: <ffffffff80128d62>{panic+134} <ffffffff8020b652>{__up_read+19}
       <ffffffff80170b04>{__fput+354} <ffffffff802d66f2>{_spin_unlock_irq+9}
       <ffffffff802d6006>{__down_read+52} <ffffffff802d67ef>{_spin_lock_irqsave+38}
       <ffffffff8020b652>{__up_read+19} <ffffffff8012c70b>{do_exit+140}
       <ffffffff8012cfa0>{sys_exit_group+0} <ffffffff8010ad82>{system_call+134}
Comment 1 Ben 2006-03-15 20:59:53 EST
Created attachment 126191 [details]
Bootlog of domU
Comment 2 Ben 2006-03-16 01:56:04 EST
OK, so it turns out I am a tard. Or SELinux is too picky. Or some combination of
those two.

In trying to disable SELinux, I accidently changed SELINUXTYPE=targeted to
SELINUXTYPE=disabled. So the config effectively said:


That probably shouldn't cause a segfault, but then again, that's probably not
what I should change it to, either.
Comment 3 Stephen Tweedie 2006-03-22 15:10:17 EST
Right, the

"Kernel panic - not syncing: Attempted to kill init!"

in that context is the kernel aborting because userland had died
catastrophically, in this case because of the SELinux config.

If you want that addresses, please feel free to reopen this bug against SELinux
or init, but it's definitely not a Xen problem.
Comment 4 Ben 2006-03-22 20:11:49 EST
re-opened against initscripts, for lack of a better place. Also bumped the
severity down, as this is entirely caused by user error.
Comment 5 Bill Nottingham 2006-03-23 12:14:27 EST
Reassigning to the component that would have to print the error.
Comment 6 Bill Nottingham 2006-08-10 13:43:07 EDT
We actually have an error printed when SELinux initialization fails, but it was
broken. Fixed in 2.86-10.
Comment 7 David Lawrence 2007-06-21 22:18:09 EDT
Package name is now sysvinit in latest Fedora.

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