Hi,
I've just moved over to an Opteron 246 dedicated server and have used up2date to install the latest kernel (2.4.21-27.0.4.Elsmp). However, when the machine reboots it never comes back up and according to the datacentre technicians, this is what's happening:
VFS: Cannot open root device"806" or 08:06 Please append a correct "root=" boot option Kernel Panic:VFS:Unable to mount root fs on 08:06
The technician then needs to reboot with the original kernel (2.4.21-27.0.2.Elsmp) to get it to work. Apparently there are no third party modules/drivers loaded. This didn't occur when I did exactly the same thing with a dual Xeon 3.06Ghz machine. Both machines use SATA drives.
Any ideas? Any pointers are greatly appreciated. Incidently, lilo.conf currently looks like this:
prompt timeout=50 default=linux boot=/dev/sda map=/boot/map install=/boot/boot.b message=/boot/message linear
image=/boot/vmlinuz-2.4.21-27.0.4.ELsmp label=newlinux initrd=/boot/initrd-2.4.21-27.0.4.ELsmp.img read-only root=/dev/sda6 image=/boot/vmlinuz-2.4.21-27.0.4.EL label=2.4.21-27.0.4.E initrd=/boot/initrd-2.4.21-27.0.4.EL.img read-only root=/dev/sda6 image=/boot/vmlinuz-2.4.21-27.0.2.ELsmp label=linux initrd=/boot/initrd-2.4.21-27.0.2.ELsmp.img read-only root=/dev/sda6
Regards,
Martyn
Martyn Drake wrote on 06 May 2005 15:45:
I've just moved over to an Opteron 246 dedicated server and have used up2date to install the latest kernel (2.4.21-27.0.4.Elsmp). However, when the machine reboots it never comes back up and according to the datacentre technicians, this is what's happening:
VFS: Cannot open root device"806" or 08:06 Please append a correct "root=" boot option Kernel Panic:VFS:Unable to mount root fs on 08:06
This is, of course, using CentOS 3.4 and is the 32-bit version.
Regards,
Martyn
Martyn Drake wrote on 06 May 2005 15:49:
Martyn Drake wrote on 06 May 2005 15:45:
I've just moved over to an Opteron 246 dedicated server and have used up2date to install the latest kernel (2.4.21-27.0.4.Elsmp). However, when the machine reboots it never comes back up and according to the datacentre technicians, this is what's happening:
VFS: Cannot open root device"806" or 08:06 Please append a correct "root=" boot option Kernel Panic:VFS:Unable to mount root fs on 08:06
This is, of course, using CentOS 3.4 and is the 32-bit version.
As a matter of interest, is there support for the Silicon Image SiI 3114 SATA controller within CentOS? The datacentre isn't sure whether it was a third party driver or not, and having not dealt with this chipset myself before, I'm not too sure either.
Regards,
Martyn
* Martyn Drake martyn@drake.org.uk [2005-05-06 16:12:48]:
Martyn Drake wrote on 06 May 2005 15:49:
Martyn Drake wrote on 06 May 2005 15:45:
I've just moved over to an Opteron 246 dedicated server and have used up2date to install the latest kernel (2.4.21-27.0.4.Elsmp). However, when the machine reboots it never comes back up and according to the datacentre technicians, this is what's happening:
VFS: Cannot open root device"806" or 08:06 Please append a correct "root=" boot option Kernel Panic:VFS:Unable to mount root fs on 08:06
This is, of course, using CentOS 3.4 and is the 32-bit version.
As a matter of interest, is there support for the Silicon Image SiI 3114 SATA controller within CentOS? The datacentre isn't sure whether it was a third party driver or not, and having not dealt with this chipset myself before, I'm not too sure either.
If it was, it sounds like you need to install that driver and rebuild the initrd for the newer kernel.
Check /etc/mod(ules|probe).conf for an "alias scsi_hostadapter ..." line. You should be able to find the module referenced in the /lib/modules directory of the old kernel, if it doesn't exist in the modules directory of the new kernel, it's walked somehow, I don't think it would be removed from a newer kernel update.
There's a sata_sil module, not sure if that covers the 3114 or just the 3112 (?) chips.
Matt
Matt Dainty wrote on 06 May 2005 16:22:
If it was, it sounds like you need to install that driver and rebuild the initrd for the newer kernel.
That's what I'm thinking, given the difference in size between the old kernel's initrd and the new kernel's initrd - the old kernel's precompiled initrd is significantly larger..
Check /etc/mod(ules|probe).conf for an "alias scsi_hostadapter ..." line. You should be able to find the module referenced in the /lib/modules directory of the old kernel, if it doesn't exist in the modules directory of the new kernel, it's walked somehow, I don't think it would be removed from a newer kernel update.
No entry exists for the module in modules.conf, and I've checked for sata_sil in both old and new /lib/modules directories and it exists in both kernel versions.
Regards,
Martyn
On Fri, May 6, 2005 10:34 am, Martyn Drake said:
Matt Dainty wrote on 06 May 2005 16:22:
If it was, it sounds like you need to install that driver and rebuild the initrd for the newer kernel.
That's what I'm thinking, given the difference in size between the old kernel's initrd and the new kernel's initrd - the old kernel's precompiled initrd is significantly larger..
Check /etc/mod(ules|probe).conf for an "alias scsi_hostadapter ..." line. You should be able to find the module referenced in the /lib/modules directory of the old kernel, if it doesn't exist in the modules directory of the new kernel, it's walked somehow, I don't think it would be removed from a newer kernel update.
No entry exists for the module in modules.conf, and I've checked for sata_sil in both old and new /lib/modules directories and it exists in both kernel versions.
Regards,
Martyn
One thing to check is if you have kernel-unsupported installed in the old kernel version. If so, make sure to install the new version as well.
Johnny Hughes wrote on 06 May 2005 17:00:
One thing to check is if you have kernel-unsupported installed in the old kernel version. If so, make sure to install the new version as well.
I decided to re-install the offending kernel RPMs and noticed this:
grubby fatal error: unable to find a suitable template
I'm wondering if it's doing mkinitrd at all. Out of curiousity, I did a manual mkinitrd and noticed that the resulting file was, like the previous new kernel install, much smaller than the 0.2 kernel version.
Still at a loss at the moment, but seeming to be making some kind of headway..
Thanks to all for their help so far, BTW.
Regards,
Martyn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 6 May 2005, at 18:02, Martyn Drake wrote:
Johnny Hughes wrote on 06 May 2005 17:00:
One thing to check is if you have kernel-unsupported installed in the old kernel version. If so, make sure to install the new version as well.
I decided to re-install the offending kernel RPMs and noticed this:
grubby fatal error: unable to find a suitable template
I'm wondering if it's doing mkinitrd at all. Out of curiousity, I did a manual mkinitrd and noticed that the resulting file was, like the previous new kernel install, much smaller than the 0.2 kernel version.
Still at a loss at the moment, but seeming to be making some kind of headway..
The older ...0.2 kernel must have the driver for your disk controller in there somewhere. If you're booted into that kernel, check dmesg for what controller gets probed.
Either the driver has been rebuilt into the kernel, (which means you're not running the original ...0.2 kernel), or it's a module, which running lsmod should confirm.
A good idea would be to post your dmesg and lsmod output with the older working kernel, along with the contents of /etc/mod{ules,probe}.conf.
Matt
Just to say, the solution was to remake the initrd manually, which has been suggested. The magic combination was this:
mkinitrd /boot/initrd-2.4.21-27.0.4.ELsmp.img 2.4.21-27.0.4.ELsmp --with=scsi_mod --with=sd_mod --with=libata --with=sata_sil --with=3w-xxxx --with=ata_piix --with=sata_sis
(remembering to remove the RPM installed initrd image file first)
Not entirely sure why this particular RPM kernel installation didn't include the driver, but it seems to be okay now.
Thanks to all for their suggestions and advice.
Regards,
Martyn