Bug 65207 - Kernel panic: No init found, with DAC960 RAID controller
Kernel panic: No init found, with DAC960 RAID controller
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Arjan van de Ven
: 64736 65099 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2002-05-20 06:49 EDT by Marco Ostini
Modified: 2005-10-31 17:00 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-06-20 07:29:59 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 Marco Ostini 2002-05-20 06:49:06 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9) Gecko/20020311

Description of problem:
After a problem free installation of RH 7.3, the first boot dies with:

Kernel panic: No init found. Try passing init= option to kernel

The hardware is a new Acer Altos 1200 with 1Gb ram, a Mylex AccelRAID 160
controller with 4x 30Gb SCSI HDD's in a RAID 5 hardware config. Processors are
2x P111 at 1.2Ghz

Redhat 7.2 works just fine on this system. Both a clean install of 7.3 or an
upgrade from 7.2 to 7.3 causes the kernel panic.

This RAID controller has been supported since RH6.2

I have checked my install media with md5sums - all matches ok 

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

How reproducible:

Steps to Reproduce:
1. Clean install of RH 7.3 or upgrade from 7.2 
2. reboot and kernel panic occours
3. I start crying & wish for stable penguins 

Actual Results:  The system locks. I have to power off.

Expected Results:  The system should chroot to the / partition and get on with

Additional info:

Just for the fun of it I tried different partition sizes and arrangement so that
there were limited partions (4) and all were primary partitions, but this made
no difference.

If I boot from the RH7.3 disc 1 into rescue mode, then I can mount all the
volumes with no problems, and chroot without problems.

The emergency boot floppy that is generated during the installation process
generates the same kernel panic as booting from the RAID array.
Comment 1 Need Real Name 2002-05-22 20:48:29 EDT
I have seen the exact same symptoms under a different configuration with a 
Mylex Acceleraid 170LP RAID controller. But so long as you boot from the RAID 
controller you get the Kernel Panic after it tries to load pivot_root
Comment 2 Need Real Name 2002-05-23 17:56:30 EDT
I can also verify this on a VA Linux 2300 upgraded from 7.2 which is now dead.
Comment 3 Marco Ostini 2002-05-24 02:15:26 EDT
**A solution was found.**

When I changed from Grub to lilo as the boot loader, the peoblem is resolved.

After booting from the 1st RH 7.3 CD into linux rescue mode, and doing a chroot 

to /mnt/sysroot I prepared the appropriate lilo.conf file in /etc, then ran; 

/sbin/lilo to modify the MBR, and it all worked perfectly.

I'm still not sure why, but switching from grub to lilo will allow a normal boot 

with no kernel panic at pivot_root

Comment 4 Steven N. Hirsch 2002-05-26 11:03:02 EDT
I believe lilo pokes the major and minor device numbers directly into the boot
image.  Grub just passes the special device path in ASCII, which fails because
the 2.4.x (for all x, I think) kernel is missing entries for /dev/rd/cCdD*
devices in init/do_mounts.c.  

Here's a patch:

--- linux-2.4.19-pre8-ac4/init/do_mounts.c.orig Thu May 16 18:55:12 2002       
+++ linux-2.4.19-pre8-ac4/init/do_mounts.c      Wed May 22 18:29:24 2002       
@@ -150,6 +150,24 @@                                                           
        { "pdd",        0x2d30 },                                              
        { "pcd",        0x2e00 },                                              
        { "pf",         0x2f00 },                                              
+#if defined(CONFIG_BLK_DEV_DAC960) || defined(CONFIG_BLK_DEV_DAC960_MODULE)   
+       { "rd/c0d0p",0x3000 },                                                 
+       { "rd/c0d1p",0x3008 },                                                 
+       { "rd/c0d2p",0x3010 },                                                 
+       { "rd/c0d3p",0x3018 },                                                 
+       { "rd/c0d4p",0x3020 },                                                 
+       { "rd/c0d5p",0x3028 },                                                 
+       { "rd/c0d6p",0x3030 },                                                 
+       { "rd/c0d7p",0x3038 },                                                 
+       { "rd/c0d8p",0x3040 },                                                 
+       { "rd/c0d9p",0x3048 },                                                 
+       { "rd/c0d10p",0x3050 },                                                
+       { "rd/c0d11p",0x3058 },                                                
+       { "rd/c0d12p",0x3060 },                                                
+       { "rd/c0d13p",0x3068 },                                                
+       { "rd/c0d14p",0x3070 },                                                
+       { "rd/c0d15p",0x3078 },                                                
        { "apblock", APBLOCK_MAJOR << 8},                                      
        { "ddv", DDV_MAJOR << 8},                                              
        { "jsfd",    JSFD_MAJOR << 8},                                         
Comment 5 Arjan van de Ven 2002-05-28 07:22:41 EDT
Nice catch!
Patch added for the next build
Comment 6 Jeremy Katz 2002-05-30 17:31:26 EDT
*** Bug 65099 has been marked as a duplicate of this bug. ***
Comment 7 Jeremy Katz 2002-05-30 17:32:37 EDT
*** Bug 64736 has been marked as a duplicate of this bug. ***
Comment 8 Martin Wilck 2002-06-07 08:59:35 EDT
I wonder whether the table in the kernel leaves out the DAC960 names.
There ought to be a reason, right? Perhaps it would be easier to fix this 
by calculating the major/minor number in anaconda's bootloader.py and insert
it directly into menu.lst rather than changing the kernel.
Comment 9 furick1 2002-06-07 23:16:09 EDT
thanks, changing to lilo worked for me.  I had a backup version of the 
lilo.conf file in /etc/ so it was easy to do.  I wonder if I update the kernel 
and switch back to grub if it will work?
Comment 10 Arjan van de Ven 2002-06-08 02:49:11 EDT
Once the kernel is released, grub should work again
Comment 11 Randall J. Parr 2002-06-10 15:23:06 EDT
I too am experiencing this problem.

Applying 2.4.18-4 kernel updates (via rpm -ivh ...) does NOT fix the problem.

That is, the following doesn't work:
Installing 7.3, 
choosing Grub, 
1st reboot via linux rescue form CD, 
chroot /mnt/sysimage, 
/sbin/service network start, 
sftp to get kernel updates,
rpm -ivh (kernel update rpms)

does NOT fix the problem. 

switching to lilo as follows does work.

cp /etc/lilo.conf.anaconda /etc/lilo.conf
lilo -v -v
Please let me know if/when this gets fixed.
I much prefer Grub.

Also note I have similar but more complicated problems trying to install onto an
IDE RAID (something I'd REALLY like to be able to do).

Temporal Arts
Comment 12 Patrick C. F. Ernzer 2002-06-20 07:29:52 EDT
workaround for those that want to use grub until the fixed kernel is released,
(from the valhalla list)

> If you're using a DAC960 based RAID controller (and it looks like you
> are), you need to pass the major and minor numbers of the root
> partition, in hex, to the kernel rather than the device name.
> Where your kernel command line is:
> kernel /boot/vmlinuz-2.4.18-3 ro root=/dev/rd/c0d0p3
> you want to change it to:
> kernel /boot/vmlinuz-2.4.18-3 ro root=3003
> On a functioning system, ls -l /dev/rd/c0d0p3 shows:
> brw-rw----    1 root     disk      48,   3 Apr 11 07:25 /dev/rd/c0d0p3
> The major number is 48 (0x30 in hex), and the minor is 3 (0x03 in hex).
> I have a 7.3 based system, and this is required to boot.
Comment 13 Need Real Name 2002-12-01 15:32:25 EST
Grub fix using root=3003 instead of /rd/c0d0p3 works for me as well. P3-450
DAC960PTL (8GB disk BIOS) , Fresh RH73 install.  Thanks all. :)

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