Red Hat Bugzilla – Bug 607186
Kernel panic - not syncing: Attempted to kill init!
Last modified: 2010-06-23 17:50:23 EDT
Created attachment 426270 [details]
complete boot log of kernel panic including call trace; captured via serial console
Description of problem:
Custom Live CD spin of Fedora 13 crashes during boot when running on an Advantech PCM-3353 PC/104 system. This same image works fine running under qemu or on an Asus Eee box.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Live CD image is copied to CompactFlash using livecd-tools' livecd-iso-to-disk utility.
2. CompactFlash plugged into PC/104 system.
3. System powered up and crashes shortly thereafter.
See attached boot log captured via serial console.
Boot successfully as with other devices.
It might also be of interest to know that a custom spin based on Fedora 12 works just fine on this same hardware.
Details of the hardware can be found here:
I have just confirmed that a stock Fedora 13 Live image crashes in the exact same way. I tried this stock image with both the CompactFlash memory card and a standard CDROM drive attached via a USB<=>IDE adapter.
Ergo, the custom spin can be ruled out.
Init process exited instantly or crash, kernel can not do anything about that.
After system load grub bootloader press 'e' and edit kernel options. Add "rdinfo" and maybe "rdinitdebug" options (see dracut man pages for other useful debug options).
Then press 'b' to make boot proceed to boot kernel. We should have some more info from init process that can give us a clue. However I'm not sure if dracut/init log on serial console, if not we have find a way to make it do that.
I have tried as you suggested by booting with both 'rdinfo' and 'rdinfo rdinitdebug' added to the kernel command line. This did not change the output in any significant way, but I've attached that here as well.
I've also tried using 'rdbreak=cmdline' which, from examination of the init script, appears to be the first available debug breakpoint. I did not get a shell when run on the problem hardware.
To ensure that I was using these options correctly, I also tried them while running the image under qemu where I did see their effect.
It appears to me that if init is getting started at all, it must be failing very early on.
Also, I have tried adding 'init=/bin/sh' and still see the same panic.
*** This bug has been marked as a duplicate of bug 579838 ***