Bug 65207

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

I can also verify this on a VA Linux 2300 upgraded from 7.2 which is now dead.

**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

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 },                                                
          
+#endif                                                                        
          
        { "apblock", APBLOCK_MAJOR << 8},                                      
          
        { "ddv", DDV_MAJOR << 8},                                              
          
        { "jsfd",    JSFD_MAJOR << 8},                                         

Nice catch!
Patch added for the next build

*** Bug 65099 has been marked as a duplicate of this bug. ***

*** Bug 64736 has been marked as a duplicate of this bug. ***

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.

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?

Once the kernel is released, grub should work again

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).

RParr
Temporal Arts

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.

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. :)