Bug 56938 - cannot upgrade kernel from 2.2.19-6.2.1 to 2.2.19-6.2.12
cannot upgrade kernel from 2.2.19-6.2.1 to 2.2.19-6.2.12
Product: Red Hat Linux
Classification: Retired
Component: mkinitrd (Show other bugs)
i686 Linux
high Severity high
: ---
: ---
Assigned To: Matt Wilson
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2001-11-30 13:17 EST by Need Real Name
Modified: 2005-10-31 17:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-05-26 17:39:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2001-11-30 13:17:24 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0; Q312461)

Description of problem:
I tried to upgrade my kernel via rpm from 2.2.19-6.2.1 to 2.2.19-6.2.12, 
but upon reboot I got a "kernel panic: cannot open root device 30:01" 

My root device (and only HD, BTW) is on device 30:01, i.e. on a Mylex RAID 
controller that requires the DAC960 scsi driver compiled into the kernel: 
I cannot see any sign of detection of the controller, so I suspect the 
driver has not been compiled in this version of the kernel

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

How reproducible:

Steps to Reproduce:
1. install the 2.2.19-6.2.12 kernel RPMs on a machine that boots from 
a "Mylex DAC960PTL1 PCI RAID Controller" (as reported from the DAC 960 
driver version 2.2.11)
2. install lilo and reboot


Actual Results:  the machine couldn't boot anymore

Expected Results:  A normal boot sequence

Additional info:
Comment 1 Arjan van de Ven 2001-12-02 11:50:43 EST
Just as with 2.2.19-6.2.1 you have to make an initrd and use that in lilo.conf...
can you check if you have done that ?
Comment 2 Need Real Name 2001-12-03 03:25:00 EST
Sorry I didn't mention it in my first post: I did make an initrd file and 
configured lilo.conf to use it. 
I do not know hot to check if everything went fine with initrd creation and/or 
if the system is using it during the boot sequence.
I can send you the output of mkinitrd -v command:

[root@myhost /root]# mkinitrd -v /boot/initrd-2.2.19-6.2.12.img 2.2.19-6.2.12
Using modules:  scsi/atp870u.o
Using loopback device /dev/loop0
/bin/ash.static -> /tmp/initrd.26227/bin/sh
/sbin/insmod.static -> /tmp/initrd.26227/bin/insmod
/lib/modules/2.2.19-6.2.12/scsi/atp870u.o -> /tmp/initrd.26227/lib/atp870u.o
Loading module atp870u with options

I cannot see any sign about DAC960 module; the command instead includes the 
driver of the 'other' SCSI card installed: but that one is only used for a SCSI 
tape, not for booting. 
Do you think I should try to include DAC960 in the initrd file using the --with 
switch? I was thinking at something like
mkinitrd /boot/initrd-2.2.19-6.2.12.img 2.2.19-6.2.12 --with=DAC960 --omit-scsi-
Comment 3 Arjan van de Ven 2001-12-03 06:05:37 EST
mkinitrd uses /etc/modules.conf to see which scsi modules need loading; can you 
check if the dac960 driver is listed in that ?
Comment 4 Need Real Name 2001-12-03 06:21:53 EST
[root@myhost /root]# cat /etc/modules.conf
alias scsi_hostadapter atp870u
alias eth0 rtl8139
alias scsi_hostadapter1 DAC960

Comment 5 Arjan van de Ven 2001-12-03 06:25:54 EST
Hrm. That should be enough to get mkinitrd to put it in the initrd... sigh
The --with DAC960 switch is worth a try
Comment 6 Need Real Name 2001-12-04 03:22:10 EST
This morning I rebooted the machine using the new initrd file created using --
with=DAC960 switch: everything is working fine now.

If I can help you to further investigate the problem with mkinitrd please let 
me know. 
From now on I will (try to) remember to use the switch whenever I will install 
a new kernel.
Comment 7 Arjan van de Ven 2001-12-04 03:26:04 EST
As this appears to be a mkinitrd bug, I'm changing the component of the bug to
mkinitrd as the kernel isn't going to fix that ;)
Comment 8 Erik Troan 2002-05-21 19:04:03 EDT
true -- hopefully massimo is still around?

if so, could you try running mkinitrd without --with, but add -v to i, and post
the output here?
Comment 9 Need Real Name 2002-05-22 03:26:49 EDT
This is the output of mkinitrd -v that ewt@redhat.com requested

# mkinitrd /boot/test.img 2.2.19-6.2.12 -v
Using modules:  block/DAC960.o scsi/atp870u.o
Using loopback device /dev/loop0
/bin/ash.static -> /tmp/initrd.15518/bin/sh
/sbin/insmod.static -> /tmp/initrd.15518/bin/insmod
/lib/modules/2.2.19-6.2.12/block/DAC960.o -> /tmp/initrd.15518/lib/DAC960.o
/lib/modules/2.2.19-6.2.12/scsi/atp870u.o -> /tmp/initrd.15518/lib/atp870u.o
Loading module DAC960 with options
Loading module atp870u with options

I also tried
mkinitrd /boot/test2.img 2.2.19-6.2.12 --with=DAC960 --omit-scsi-modules -v
Using modules:  block/DAC960.o
Using loopback device /dev/loop0
/bin/ash.static -> /tmp/initrd.15820/bin/sh
/sbin/insmod.static -> /tmp/initrd.15820/bin/insmod
/lib/modules/2.2.19-6.2.12/block/DAC960.o -> /tmp/initrd.15820/lib/DAC960.o
sed: can't read /etc/conf.modules: No such file or directory
Loading module DAC960 with options

So apparently mkinitrd is looking for /etc/conf.modules, but I only 
have /etc/modules.conf

Hope this helps
Comment 10 Erik Troan 2002-05-22 13:29:12 EDT
Hmmm... mkinitrd should prefer modules.conf to conf.modules.. don't know where
that's coming from.

Could you run both of those with "sh -x mkinitrd <your-options>" and mail the
output, along with the resulting initrd images, directly to me at ewt@redhat.com?

Comment 11 Need Real Name 2002-05-23 06:03:38 EDT
I have just emailed you the info requested
Comment 12 Erik Troan 2002-05-26 17:39:11 EDT
Got it -- thanks.

You're running a very old version of mkinitrd (it looks like version 2.3, which
is from 1999)... The conf.modules problem you're seeing is a relic from that as
far as I can tell.

I don't know if either of the test images you sent me work or not; I'm guessing
that the one created with the --with switch works, and the other one doesn't?

The only difference between them is that the disk created w/ --with does not try
to load atp870u. I suspect this is actually a bug, but it's pretty irrelevant.
If the module that tries to load atp870u prevents your system from booting, it's
a problem with that module being loaded so early in the boot

Please let me know if the initrd created w/o the --with=DAC960 doesn't work
while the other one does. If that is the case, this is a kernel bug with that
module. If neither works, it's probably still a kernel bug.
Comment 13 Erik Troan 2002-06-19 22:42:43 EDT
Guess things work? Closing bug due to inactivity.

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