Bug 27394 - kernel-smp-2.2.17-14smp.i686.rpm kernel panic
kernel-smp-2.2.17-14smp.i686.rpm kernel panic
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: mkinitrd (Show other bugs)
6.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Matt Wilson
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-13 10:37 EST by Need Real Name
Modified: 2007-04-18 12:31 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-22 14:29:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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-02-13 10:37:10 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)


I tried to upgrade the kernel of my box (Dell Precision 410, Dual Peintium-
II 450MHz with AIC-7890 and AIC 7880 SCSI on-board adaptors) to 2.2.17-
14smp, but it gotkernel panic at boot time.

The old kernel 2.2.16-3smp works just fine.



Reproducible: Always
Steps to Reproduce:
1. "rpm -i" the new kernel RPM file
2. mkinitrd for the new kernel
3. edit /etc/lilo.conf to add the new kernel
4. "lilo"
5. reboot
	

Actual Results:  .
.
.
kmod: failed to exec /sbin/modprobe -s -k block-major-8, error=2
VFS: Cannot open root device 08:01
Kernel panic: VFS: Unable to mount root fs on 08:01

I've successfully upgraded other Linux boxes to 2.2.17-14smp.i686. They are

1. Dual Pentium II 300MHz with on-board AIC-7880 SCSI conctroller
2. Dual Pentium III 5000MHz with AHA=294X adapter

it seems that the new kernel has some problem with AIC-7890,7880 
controllers????
Comment 1 Michael K. Johnson 2001-02-13 19:50:41 EST
Doug, please investigate
Comment 2 Pekka Savola 2001-02-14 19:21:57 EST
Try passing '--with aic7xxx' (or --preload) option to mkinitrd.
Comment 3 Need Real Name 2001-02-14 20:16:14 EST
When I tried "mkinitrd --with aic7xxx", it complaied "no /etc/conf.modules" 
something like that. Thus I "ln -s /etc/modules.conf /etc/conf.modules" 
and "mkinitrd" without "--with aic7xxx" option. And guess what? it works!!!

I bet somehow the kernel or the mkinitrd command is confused about whether 
it's /etc/conf.modules or /etc/modules.conf ONLY WHEN the machine has TWO on-
board SCSI controllers??? As I mentioned, the kernel and mkinitrd worked quite 
well on machines with only 1 SCSI controller and without /etc/conf.moduels.

Comment 4 Pekka Savola 2001-02-15 02:49:08 EST
Had you compiled your own kernel on the system with two controllers?  If
mkinitrd
can't see the modules in 'lsmod', it'll try to add them, AFAIR.

This is a thing to remember if you're creating mkinitrd on your own custom
rescue disk.  I've
been bitten by it a lot of times :-)
Comment 5 Need Real Name 2001-02-15 05:05:09 EST
No. For more than a year, I have been updating the box using only RPM files 
from RedHat. kernel-smp-2.2.17-14.i686.rpm is the first one that has this 
problem. For example, the previously released RPM files like kernel-smp-2.2.16-
3.i686.rpm have no such a problem and work just fine.
Comment 6 Doug Ledford 2001-02-21 19:05:04 EST
Obviously, this isn't a kernel bug.  More likely it's a mkinitrd bug.  For
future reference, whenever making an initrd it is wise to use the -v flag so you
can see what modules are actually being put into the initrd image.  This habit
has saved me a lot of grief in the past.
Comment 7 Need Real Name 2001-02-22 14:29:25 EST
This appears to be a result of the 2.2.17-14 kernel changing /etc/conf.modules
into /etc/modules.conf on 6.x boxes that don't have a modutils that is capable
of handling /etc/modules.conf transparently.  6.0 I know falls into this
category, maybe 6.1.  We should probably put out something letting 6.x users
know that they need to update modutils as that package is not in the updates
directory for all 6.x versions.
Comment 8 Erik Troan 2002-05-21 18:55:21 EDT
probably, but it's a bit late for that now

killing this due to old age... reopen if necessary

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