Description of problem: The boot process failed with the error: mount: error mounting /dev/root on /sysroot as ext3: No such file or direct Version-Release number of selected component (if applicable): Starting from kernel-2.6.27.12-170.2.5.fc10 (kernel-2.6.27.9-159 was the last known to work). How reproducible: kernel-2.6.27.9-159.fc10.x86_64 and older worked (not tested with F-10 GA kernel) kernel-2.6.27.12-170.2.5.fc10.x86_64 and newer failed. Steps to Reproduce: 1. boot on kernel 2.6.27.12-170.2.5.fc10 or older 2. see the error message during the boot process Actual results: boot failed. Expected results: boot succeed. Additional info: * On this system, http://www.smolts.org/show?uuid=pub_c03a1eea-f904-4743-bb2c-dd40aa32b12e I've also experienced theses bugs: https://bugzilla.redhat.com/show_bug.cgi?id=481595 https://bugzilla.redhat.com/show_bug.cgi?id=475283 Initrd images are significantly smaller than the previous ones: [root@kwizatz boot]# export LANG=C; ls -alh initrd-2.6.2* root root 3.4M Jan 27 02:29 initrd-2.6.27.12-170.2.5.fc10.x86_64.img root root 3.8M Dec 30 22:30 initrd-2.6.27.9-159.fc10.x86_64.img * This problem was reproduced another time on a different system that I cannot access for now (nforce2 - single harddisk) * It is also reported on this topic from the fr forum: http://forums.fedora-fr.org/viewtopic.php?id=38911
Do you use dmraid? The initrd images are gzipped cpio archives. Can you look inside the two initrds to compare them and see what's missing in the new one?
In could also be a bug in mkinitrd if it was updated recently. Try this: mkinitrd /boot/initrd.test 2.6.27.9-159.fc10.x86_64 And compare the size of initrd.test with initrd-2.6.27.9-159.fc10.x86_64.img. You can delete initrd.test afterwards.
Created attachment 330100 [details] diff between listing of the initrd images listing the file in the uncompressed directory: /bin/lvm was missing (along the the related dependencies and configuration files) The current lvm2 version comes from the fedora updates repository: lvm2-2.02.39-7.fc10.x86_64
mkinitrd-6.0.71-3.fc10.x86_64 The initrd.test is indeed, smaller than the initial initrd-2.6.27.9-159.fc10.x86_64.img
I'm trying with the mkinitrd GA version
reverting nash mkinitrd and libbdevid-python to the GA version (6.0.71) didn't raise the size of the initrd to the working one.
FWIW, I'm seeing similar issues with >= 2.6.28 upstream kernels on F10 userland, especially recent wireless-testing (2.6.29-rc2 based)...
FWIW comment 7 is no longer valid -- oddly, I don't recall any update that made it work... :-(
Hi, Same problem on my system : http://www.smolts.org/client/show/pub_2a780bec-8446-4bfa-a445-0a0777e38a1a Everything ok with 2.6.27.9-159. Unable to boot properly with 2.6.27.12-170
I have two identical machines, concerning hardware except for one thing. One machine uses a sata 3 hdd and the other uses an IDE hdd. The IDE hdd boots the 170 version of the kernel boots fine while the sata does not.
Mine has 3 hdds : 1 PATA and 2 SATA Boot device is the PATA one (sdc) /, /home and swap are on sdc in a vg result of fdisk -l : Disque /dev/sda: 500.1 Go, 500107862016 octets 255 heads, 63 sectors/track, 60801 cylinders Units = cylindres of 16065 * 512 = 8225280 bytes Disk identifier: 0x0009ce00 Périphérique Amorce Début Fin Blocs Id Système /dev/sda1 * 1 30401 244196001 83 Linux /dev/sda2 30402 60801 244188000 8e Linux LVM Disque /dev/sdb: 200.0 Go, 200049647616 octets 255 heads, 63 sectors/track, 24321 cylinders Units = cylindres of 16065 * 512 = 8225280 bytes Disk identifier: 0x00069857 Périphérique Amorce Début Fin Blocs Id Système /dev/sdb1 1 24321 195358401 7 HPFS/NTFS Disque /dev/sdc: 122.9 Go, 122942324736 octets 255 heads, 63 sectors/track, 14946 cylinders Units = cylindres of 16065 * 512 = 8225280 bytes Disk identifier: 0x000630df Périphérique Amorce Début Fin Blocs Id Système /dev/sdc1 * 1 66 530113+ 83 Linux /dev/sdc3 67 14946 119523600 8e Linux LVM
From Rawhide report: mkinitrd-6.0.76-1.fc11 ---------------------- * Wed Feb 4 17:00:00 2009 Hans de Goede <hdegoede> - 6.0.76-1 ... - Handle lv root specified as /dev/dm-X properly (#471729) Actually changing /dev/dm-? to the matching LVM form bring back the lvm2 binary in the initrd image (and the kernel is allowed back to boot). I may close this bug as duplicate of 475773 It remains the kpartx problem to be seen. (aka 475283 )
Of the two identical machines I used, one with the error and one without I noticed the one that would not boot was installed and updated with the 2.6.27.9-159 kernel and then to the 2.6.27.12-170. The one that did work was installed and updated directly to the 2.6.27.12-170 kernel. I reinstalled F10 from the DVD local media on the machine that had the bug and then updated directly to the 2.6.27.12-170. The machine booted normally without the error. My conclusion is the 2.6.27.9-159 kernel is where the problem lies. This information is not arrived at through any scientific method or with any real knowledge of kernel construction or specific knowledge as to the workings of F10. Perhaps if 2.6.27.9-159 is removed prior to the installation of 2.6.27.12-170 this error might be avoided.
Closing this as a dup of bug 475773 (per comment #12) *** This bug has been marked as a duplicate of bug 475773 ***