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 http://hardware.redhat.com/hcl/genpage2.cgi?pagename=hcl&view=certified&vendor=16&class=8#list I have checked my install media with md5sums - all matches ok Version-Release number of selected component (if applicable): How reproducible: Always 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 things. 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.
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. :)