Description of problem:
kernel-2.6.0-1.21 is not able to find the root device "LABEL=/".
mkinitrd is at version 22.214.171.124-1. Both kernel's initrd.img files look
the same upon unpacking them, the same modules, etc.
Steps to Reproduce:
1. rpm -ivh kernel-2.6.0-1.21.i686.rpm
Prints out the following (copied to paper from the screen):
VFS: Mounted root (ext2 file system)
Red Hat nash version 126.96.36.199 starting
Loading jd.ko module
Loading ext3.ko module
Creating block devices
VFS: Cannot open root device "LABEL=/" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on unknown-block(0,0)
Should work as 2.6.0-0.1.14 and earlier ones did.
My /etc/grub.conf looks the following and the entry for 2.6.0-0.1.14
title Fedora Core (2.6.0-1.21)
kernel /boot/vmlinuz-2.6.0-1.21 ro root=LABEL=/ acpi=on
title Fedora Core (2.6.0-0.1.14)
kernel /boot/vmlinuz-2.6.0-0.1.14 ro root=LABEL=/ acpi=on
Ok, downgraded mkinitrd to 188.8.131.52-2 and the kernel is able to boot
Seems like the problem would be the patch from Al Viro? (3.5.16 and up?)
Changing component to mkinitrd.
*** Bug 112037 has been marked as a duplicate of this bug. ***
I am seeing this with 2.6.0-1.107, mkinitrd-184.108.40.206-1.
Seems to me that the cause is that the linuxrc script no longer mounts
/proc (but mounts /sys instead), so the nash "mkdevices" fails (which
needs /proc/partitions), so it all falls down.
Maybe all this can be done via /sys, too, but nash does not know about it.
The same problem happens in kernel-2.6.0-1.23, mkinitrd-220.127.116.11-1.
but The problem didn't happen in kernel-2.6.0-1.21, mkinitrd-18.104.22.168-1.
I don't have that problem with kernel-2.6.0-1.23 but my mkinitrd
package is already downgraded to FC1's initial version.
sangu: verify install order with rpm -qa --last, I bet your
kernel-2.6.0-1.21 was installed before mkinitrd-22.214.171.124-1.
ralf: /proc is mounted as usual within linuxrc, you can verify it
yourself by ungzipping the inird image and mounting it as -o loop
Yes, it looks like the problem would be within mkdevicesCommand() in
Kaj J. Niemi : You're right. Thank your comments.
This will be fixed in 3.5.17 built against a newer dietlibc
(dietlibc-0.24-1 had a slightly broken snprintf)