Bug 56938 - cannot upgrade kernel from 2.2.19-6.2.1 to 2.2.19-6.2.12
Summary: cannot upgrade kernel from 2.2.19-6.2.1 to 2.2.19-6.2.12
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: mkinitrd   
(Show other bugs)
Version: 6.2
Hardware: i686
OS: Linux
high
high
Target Milestone: ---
Assignee: Matt Wilson
QA Contact: Brock Organ
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-11-30 18:17 UTC by Need Real Name
Modified: 2005-10-31 22:00 UTC (History)
1 user (show)

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


Attachments (Terms of Use)

Description Need Real Name 2001-11-30 18:17:24 UTC
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" 
error.

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:
Always

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 16:50:43 UTC
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 08:25:00 UTC
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-
modules


Comment 3 Arjan van de Ven 2001-12-03 11:05:37 UTC
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 11:21:53 UTC
[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 11:25:54 UTC
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 08:22:10 UTC
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 08:26:04 UTC
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 23:04:03 UTC
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 07:26:49 UTC
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 17:29:12 UTC
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 10:03:38 UTC
I have just emailed you the info requested


Comment 12 Erik Troan 2002-05-26 21:39:11 UTC
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
sequence.

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-20 02:42:43 UTC
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.