I don't think that the hot-plug is even recognised at this moment, as I understand that the kernel version does not support the hot-plug scsi tape on the compaq smart array. Tha's the reason why I downloaded a later kernel and compiled it. The original kernel is still there, untouched, and if I did not meddle with grub-install, it could boot the original kernel correctly.
The main problem I encounter was that grub did not seem to recognise the changes I did to /etc/grub.conf (I edited it manually). This is what I thought would have worked: 1) Compile kernel, compile and install modules under /lib/modules 2) place the bzImage as /boot/vmlinuz-XXXXX 3) modify grub.conf to point to the correct vmlinuz file 4) reboot However, when I rebooted, and chose the new kernel, I got the kernel panic. That's when I tried to see if new-kernel-pkg and grubby could help me configure grub correctly. In the process, I tried grub-install, thinking that it would set the new kernel correctly. However, as you have mentioned, it could have messed up the MBR in the process. I have a new option now, which is to upgrade this system to RedHat 7.3, and let the RedHat installer to correct the MBR in the process. Would this be a better idea than to waste time figuring out how to set the MBR manually on the command line? Eng Hee -----Original Message----- From: Thierry Laronde [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 2:02 AM To: Yeo Eng Hee Cc: [EMAIL PROTECTED] Subject: Re: Problems with Compaq DL380G2 running Redhat 7.2 On Thu, May 30, 2002 at 05:21:43PM +0800, Yeo Eng Hee wrote: > I am encountering a problem with the bootloader. > > Everything worked fine until I had to compile and install my own > kernel. (I needed to run Linux 2.4.22 kernel to access the hot-plug > tape that comes with the DL380G2). > > I tried configuring grub using new-kernel-pkg and grubby, but when I > reboot, I got a kernel panic with a message saying the my root fs is > not mounted, "cciss/c0d0p1" not valid and to set root= properly (I am > writing this from memory). I think some people from RedHat are listening to the list. Because since `new-kernel-pkg' and `grubby' are neither part of the GRUB vanilla or standard on other distributions, it will be difficult to debug without knowing exactly what these utils do... Apart from this, is the hot-plug tape your root device (do you boot from this) or are you still booting from the hard disk? If this is the latter, either change the default root device of your kernel via `rdev(8)' and read `bootparam(7)' in order to know what boot time configuration parameters are needed for your kernel/devices. Since the kernel is loaded, GRUB has done its job well. The remaining errors are wrong arguments passed to the kernel. For the second time problems, it seems to me that the informations in stage1 have been spoiled by the failed `grub-install'. If, here, only the vanilla `grub-install' has spoiled its data (writing something without being sure to he able to run), there is a bug. But I'm a bit suspicious about this one too. Is the `grub-install' on RedHat modified in order to query from the kernel the root partition (invoquing rdev for example)? So, the diagnostic (looking without having a RedHat system). GRUB is able to load the kernel --- I guess from the disk, but the parameters are wrong (and this will not be solved by another bootloader, since this is not a bootloader problem). When recompiling your kernel, your tape has been taken as the root device (which is probably wrong), and a version of `grub-install' (alone or via another front-end? vanilla or not?) seems to have taken this info and spoilt the MBR. Hence three levels of responsability: 1) Has a _vanilla_ `grub-install' spoilt a MBR? --- not sure 2) Has RedHat changed something? --- sure for a part, but unsure that these parts are at fault in this very case 3) User (_you_): you have recompiled the kernel, which is special and needs boot time info via the bootparameters, bootparameters that you have not provided: this is the initial root of the problems and the explanation of the initial `panic'. So getting the correct parameters for your kernel, and reinstalling a bootloader (GRUB has demonstrated that it is working) with the correct bootparameters will solve the problem. But questions 1 and 2 need to be clarified. Cheers, -- Thierry Laronde (Alceste) <[EMAIL PROTECTED]> Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
smime.p7s
Description: application/pkcs7-signature