Just did a rather massive yum update of an FC5 system. The update include updating kernel from .... to 2.6.20-1.2312.fc5
System is an IBM Thinkpad T42
The system will not boot the new kernel. Skipping the first lines (grub stuff) the screen shows: Uncompressing Linux... Ok, booting the kernel. Red Hat nash version 5.0.32 starting Unable to access resume device (/dev/VolGroup00/LogVol01) mount: could not find filesystem '/dev/root'
followed by the expected messages such as "moving /dev failed"
It almost looks like the boot things that it is coming out of "suspend" rather than booting the kernel, unless the wording of that message is bogus about "unable to access resume device". Any ideas anyone?
John DeDourek wrote:
Just did a rather massive yum update of an FC5 system. The update include updating kernel from .... to 2.6.20-1.2312.fc5
System is an IBM Thinkpad T42
The system will not boot the new kernel. Skipping the first lines (grub stuff) the screen shows: Uncompressing Linux... Ok, booting the kernel. Red Hat nash version 5.0.32 starting Unable to access resume device (/dev/VolGroup00/LogVol01) mount: could not find filesystem '/dev/root'
followed by the expected messages such as "moving /dev failed"
It almost looks like the boot things that it is coming out of "suspend" rather than booting the kernel, unless the wording of that message is bogus about "unable to access resume device". Any ideas anyone?
The "unable to access resume device" is the kernel trying to see if it is a fresh boot, or a resume after hibernation. From the prospective of GRUB, they are the same. The kernel then checks the swap space for a hibernation signature, to help it decide weather to do a fresh boot, or a resume. This looks more like you have a bad Initial RAM disk. The kernel is not able to access the Logical Volumes for some reason.
Mikkel
On Mon, 2007-04-16 at 13:19 -0300, John DeDourek wrote:
Just did a rather massive yum update of an FC5 system. The update include updating kernel from .... to 2.6.20-1.2312.fc5
And if you boot from the old kernel, do things work again?
Tim wrote:
On Mon, 2007-04-16 at 13:19 -0300, John DeDourek wrote:
Just did a rather massive yum update of an FC5 system. The update include updating kernel from .... to 2.6.20-1.2312.fc5
And if you boot from the old kernel, do things work again?
Yes. No problem with that. It still boots and runs fine under the old kernel.
A previous reply suggested that the new kernel might have a bad initrd.
Can anyone tell me whether the initrd is installed as a binary from the kernel package, or is custom built by a script during the install process? If the latter, I am inclined to remove and reinstall the new kernel, thus rebuilding the new initrd. (Or, I will find the instructions for rebuilding the initrd manually.)
John DeDourek wrote:
Yes. No problem with that. It still boots and runs fine under the old kernel. A previous reply suggested that the new kernel might have a bad initrd. Can anyone tell me whether the initrd is installed as a binary from the kernel package, or is custom built by a script during the install process? If the latter, I am inclined to remove and reinstall the new kernel, thus rebuilding the new initrd. (Or, I will find the instructions for rebuilding the initrd manually.)
It is built during the install. This is because it is specific to the system it is installed on. It is created by running mkinitrd.
Mikkel
On Tue, 2007-04-17 at 07:34 -0300, John DeDourek wrote:
A previous reply suggested that the new kernel might have a bad initrd.
Can anyone tell me whether the initrd is installed as a binary from the kernel package, or is custom built by a script during the install process?
rpm -ql kernel |grep init /lib/modules/2.6.19-1.2911.6.4.fc6/kernel/drivers/scsi/initio.ko /lib/modules/2.6.19-1.2911.6.5.fc6/kernel/drivers/scsi/initio.ko /lib/modules/2.6.20-1.2925.fc6/kernel/drivers/scsi/initio.ko /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/scsi/initio.ko /lib/modules/2.6.20-1.2944.fc6/kernel/drivers/scsi/initio.ko
Doesn't look to me that it comes predefined with the kernel, and makes sense that it's generated to suit the particular system.
If the latter, I am inclined to remove and reinstall the new kernel, thus rebuilding the new initrd. (Or, I will find the instructions for rebuilding the initrd manually.)
I think it'd be easy enough to remove the latest kernel, check that the /boot/init.... file for it has been removed, then try again. Otherwise study mkinitrd, but it's not something I've ever looked at.
Tim wrote:
On Mon, 2007-04-16 at 13:19 -0300, John DeDourek wrote:
Just did a rather massive yum update of an FC5 system. The update include updating kernel from .... to 2.6.20-1.2312.fc5
And if you boot from the old kernel, do things work again?
Actually, my next guess is that I have been bitten by bug Bugzilla # 220470 or something related. It appears that the 2.6.20 series of kernel are trying to build all drivers as modules rather than building the basic disk access modules into the kernel source. This means that after the kernel boots, something loads these drivers from the initrd. On some systems there is a timing issue because the necessary /proc and/or /sys "files" only appear after the driver is loaded and initialized and something may look for these files "too soon".
If removing and reinstalling the kernel doesn't fix the problem, I will file a Bugzilla report.