Hide Forgot
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): 2.6.33.5-124.fc13.i686 How reproducible: always 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. Actual results: See attached boot log captured via serial console. Expected results: Boot successfully as with other devices. Additional info: 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: http://www.advantech.com/products/PCM-3353/mod_1-2JKGV9.aspx
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 ***