Red Hat Bugzilla – Bug 61272
kernel panic on first boot
Last modified: 2007-04-18 12:40:58 EDT
Description of Problem:
Server : DL360 G2
OS : RedHat 8.0 beta 1 && beta 2
Boot ctlr : Embedded Smart Array 5i ctlr (cciss - RAID 1)
RedHat 8.0 installation completed on DL 360G2(GRUB). At the end of installation
following error messages obeserved on the screen.
/usr/lib/anaconda/iw/progress_gui.py:98: DeprecationWarning : Use
/usr/lib/anaconda/iw/progress_gui.py:98: DeprecationWarning :
self.totalprogress.update (float(self.sizeComplete) / self.toatlSize.
Rebooted the system after installation. kernel panic is observed with the
mount : error 2 mounting ext 3
pivtroot: pivot_root(/sysroot, /sysroot/initrd) failed : 2
Kernel panic : No init found : Try passinf init = option to kernel.
This also happens on DL 330G2..
There's at least some confusion here since the messages given would only occur
in beta1 and not in beta2. What does the bootloader config look like?
I'm seeing this with Skipjack-re0318.1 on 2 different DL380s.
One has the Smart Array 5i (cciss) controller. The other has an "Integrated
Smart Array Controller (ver 1.40)" (cpqarray).
Both are giving me the kernel panic as above (although I have not personally
observed the end of installation message -- these wer kickstart installs).
With a newer tree (Skipjack-re0320.0) I'm still seeing the cciss lock, but the
cpqarray seems to have booted.
I have serial captured the boot messages, will attach.
Created attachment 49267 [details]
serial capture of cciss system (DL380) kernel panic
In the above capture, there is a notable pause (several seconds) between the
following two lines:
blk: queue f7fb9e1c, I/O limit 4095Mb (mask 0xffffffff)
Loading sym53c8xx module
Is this system set up in the lab?
At least one of these boxes (the 2-U DL380) has a symbios SCSI adapter in it.
I'm guessing that the panic has to do w/ the 'mkinitrd' errors I found in the
install.log (after booting w/ linux rescue).
see bug# 60242
Fixed in mkinitrd-3.3.6 and newer
Can the bug reporter please verify this is fixed against a recent tree?
Could compaq please test the latest Skipjack beta so we can confirm this fix?
I haven't seen this bug with any of the recent trees (and that would include
Skipjack public beta 2). My testing includes the two machines in the lab that
manifested the bug before (one cciss and one cpqarray).
Sounds good; thanks for testing Mike