Bug 481761 - error mounting /dev/root on /sysroot with kernel
error mounting /dev/root on /sysroot with kernel
Status: CLOSED DUPLICATE of bug 475773
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-01-27 09:45 EST by Nicolas Chauvet (kwizart)
Modified: 2009-02-10 04:57 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-02-10 04:57:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
diff between listing of the initrd images (4.64 KB, text/plain)
2009-01-27 10:22 EST, Nicolas Chauvet (kwizart)
no flags Details

  None (edit)
Description Nicolas Chauvet (kwizart) 2009-01-27 09:45:04 EST
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- 
(kernel- was the last known to work).

How reproducible:
kernel- and older worked (not tested with F-10 GA kernel)
kernel- and newer failed.

Steps to Reproduce:
1. boot on kernel or older
2. see the error message during the boot process
Actual results:
boot failed.

Expected results:
boot succeed.

Additional info:
* On this system,
I've also experienced theses bugs:
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-
root root 3.8M Dec 30 22:30 initrd-

* 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:
Comment 1 Michal Schmidt 2009-01-27 09:58:03 EST
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?
Comment 2 Michal Schmidt 2009-01-27 10:02:23 EST
In could also be a bug in mkinitrd if it was updated recently. Try this:

mkinitrd /boot/initrd.test

And compare the size of initrd.test with initrd-
You can delete initrd.test afterwards.
Comment 3 Nicolas Chauvet (kwizart) 2009-01-27 10:22:05 EST
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:
Comment 4 Nicolas Chauvet (kwizart) 2009-01-27 10:32:07 EST

The initrd.test is indeed, smaller than the initial initrd-
Comment 5 Nicolas Chauvet (kwizart) 2009-01-27 10:33:23 EST
I'm trying with the mkinitrd GA version
Comment 6 Nicolas Chauvet (kwizart) 2009-01-27 10:41:38 EST
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.
Comment 7 John W. Linville 2009-01-27 13:12:38 EST
FWIW, I'm seeing similar issues with >= 2.6.28 upstream kernels on F10 userland, especially recent wireless-testing (2.6.29-rc2 based)...
Comment 8 John W. Linville 2009-01-28 17:03:51 EST
FWIW comment 7 is no longer valid -- oddly, I don't recall any update that made it work... :-(
Comment 9 Arnaud Dubois 2009-01-31 17:53:27 EST

Same problem on my system :

Everything ok with

Unable to boot properly with
Comment 10 will edwards 2009-01-31 18:07:36 EST
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.
Comment 11 Arnaud Dubois 2009-01-31 18:31:22 EST
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
Comment 12 Nicolas Chauvet (kwizart) 2009-02-05 05:35:04 EST
From Rawhide report:

* Wed Feb  4 17:00:00 2009 Hans de Goede <hdegoede@redhat.com> - 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 )
Comment 13 will edwards 2009-02-05 10:42:35 EST
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 kernel and then to the  

The one that did work was installed and updated directly to the kernel.

I reinstalled F10 from the DVD local media on the machine that had the bug and then updated directly to the The machine booted normally without the error.  My conclusion is the 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 is removed prior to the installation of this error might be avoided.
Comment 14 Hans de Goede 2009-02-10 04:57:07 EST
Closing this as a dup of bug 475773 (per comment #12)

*** This bug has been marked as a duplicate of bug 475773 ***

Note You need to log in before you can comment on or make changes to this bug.