topic Kernel panic problem when updating in Operating System - Linux

Kernel panic problem when updating

Leibniz — Mon, 16 Jun 2008 15:29:47 GMT

Hello:

We have a problem with which I hope someone can help.

Server: ProLiant BL460c G1
O/S: RHEL 4 AS 32bit
Kernel: 2.6.9-55.0.9.ELsmp
QLogic: 8.01.04-d8
CPUs: 2 x dual core 3.0GHz

We have two HBAs with SAN attached. 8 LUNS visible and configured with Powerpath on both cards, and 8 more LUNS not configured, but visible via one adapter (port.) EMC san.

$ dmesg | grep Found
qla2400 0000:10:00.0: Found an ISP2432, irq 185, iobase 0xf883c000
qla2400 0000:10:00.1: Found an ISP2432, irq 193, iobase 0xf886a000
qla2400 0000:13:00.0: Found an ISP2432, irq 193, iobase 0xf886c000
qla2400 0000:13:00.1: Found an ISP2432, irq 169, iobase 0xf886e000

QLogic update archive we are trying to apply is this one:
-rw-r----- 1 root root 2006988 Nov 23 2007 qla2xxx-v8.01.07.15-2-dist.tgz

Current configuration is working fine, but when we try to update either the qlogic driver (to 8.01.7-15) or the kernel (to -67, or -67.0.1, or 67.0.4, or 67.0.15) we get a kernel panic.

We do have about 120 RPM packages that need updating on that server, but we have a many other blades in the same situation - requiring some updates and with the same HBA cards, that do not experience this panic problem [and are at -67 kernel level], so we are thinking that although the server needs updating, that may not be the problem. (Although I did update device-mapper and device-mapper-multipath, thinking it might be the problem. Wasn't.) However, up2dating the system is our next step, should we not find a more plausable reason for the panic.

This is the output I see when trying to update the qlogic driver (extract archive, ./drvinstall, cd src dir, ./extras/build.sh install, mkinitrd, modify menu.lst, and reboot) or kernel:

============================================
QLogic Fibre Channel HBA Driver: 8.01.07.15-fo
QLogic QMH2462 -
ISP2432: PCIe (2.5Gb/s x4) @ 0000:13:00.1 hdma+, host#=3, fw=4.00.26 [IP]
Loading dm-mod.ko module
defice -mapper: 4.5.5-ioctl (2006-12-01) initialised: dm-devel@redhat.com
Loading jbd.ko module
Loading ext3.ko module
Creating root device
mkrootdev: label / not found
Mounting root filesystem
mount: error 2 mounting ext3
mount: error 2 mounting none
Switching to new root
switchroot: mount failed: 22
umount /initrd/dev failed: 2
Kernel panic - not syncing: Attempted to kill init!
============================================

As this server is currently production, we don't have the luxury of trying different methods at will (like up2dating the system.)

Thoughts?

Thanks in advance for any assistance with this.

Regards,
Bill

Re: Kernel panic problem when updating

Steven E. Protter — Mon, 16 Jun 2008 20:17:20 GMT

Shalom,

You might wish to build a yum repository server inside your organization. This would use up2date to get the patches in house and permit you to archive off tested patch sets that are less likely to kill your production server.

http://www.webmo.net/support/yum_repository.html

SEP

Re: Kernel panic problem when updating

Leibniz — Mon, 16 Jun 2008 21:19:33 GMT

We have an in-house satellite server. That should be enough, I'd think.

The problem is that this is not consistent across all RHEL 4 AS servers in our environment. We have dozens of 4AS servers with QLogic HBA cards, and the ony upgrade problem we have is with this one particular server. And it was only built six months ago, so it really isn't even that old. And yet, the problem persists.

Since this kernel panic occurs when simply booting off a more recent kernel, I'm inclined to think that the problem may not be QLogic related. That said, the newer kernels were installed and the initrd does house the older (8.01.04) QLogic driver, so it might still be an old driver problem. Since it panics with a newer QLogic driver too, I'm inclined it's a more system related problem.

Nothing specific shows up in the log file, but then why would it - since it crashes before it gets into even single user mode. We may just have to send a crash dump to RedHat, I don't know. It's just a bit farther down the agenda at this point.

Still looking for some insight.

Thanks all.
Bill