Bug 475773 - mkinitrd and /dev/dm-* issues
mkinitrd and /dev/dm-* issues
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
10
i386 Linux
low Severity high
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
: 471729 481761 497246 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-10 07:45 EST by Sameer Naik
Modified: 2009-05-26 05:19 EDT (History)
13 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Sameer Naik 2008-12-10 07:45:50 EST
Description of problem:
Creating initrd.img when the disk has logical volumes results in unbootable initrd image.

Version-Release number of selected component (if applicable):
fedora release version as well as mkinitrd-6.0.71-3.fc10.i386 from koji

How reproducible:
My system had the following mountpoints in the fstab. 
/dev/dm-* refer to my fedora installation partitions (LVM)

tmpfs                 /dev/shm        tmpfs   defaults        0       0
devpts                /dev/pts        devpts  gid=5,mode=620  0       0
sysfs                 /sys    sysfs   defaults                0       0
proc                  /proc   proc    defaults                0       0
/dev/dm-0             /       ext3    defaults                1       1
/dev/dm-1             /opt    ext3    defaults                1       2
/dev/dm-2             /home   ext3    defaults                1       2
/dev/dm-3             swap    swap    defaults                0       0

creating an initrd.img using the following command
mkinitrd -f /boot/initrd-$(uname -r).img $(uname -r)

resulted in an image, with which if i did a boot with threw the following error messages

Unable to access resume device /dev/dm-3
mount: error mounting /dev/root on /sysroot as ext3: No such file of directory

I had also received these errors when i did an install of ndiswrapper enabled kernel using fedora/rpmfusion repositories


Additional info:
When i got rid of the /dev/dm-* mountpoints from the fstab everthing was ok.
i made changes so that my fstab looked like this.

tmpfs             /dev/shm    tmpfs   defaults                        0       0
devpts            /dev/pts    devpts  gid=5,mode=620                  0       0
sysfs             /sys        sysfs   defaults                        0       0
proc              /proc       proc    defaults                        0       0
/dev/primary/root /           ext3    defaults                        1       1
/dev/primary/opt  /opt        ext3    defaults                        1       2
/dev/primary/home /home       ext3    defaults                        1       2
/dev/primary/swap swap        swap    defaults                        0       0

NOTE: "primary" is the name of my volume group
      "root" is the name of the root logical volume
      "opt" is the name of the opt logical volume
      "home" is the name of the home logical volume
      "swap" is the name of the swap logical volume

I believe there is a bug in mkinitrd, that needs to correctly handle these /dev/dm-* mountpoints.
Comment 1 Hans de Goede 2009-02-03 05:47:00 EST
*** Bug 471729 has been marked as a duplicate of this bug. ***
Comment 2 Hans de Goede 2009-02-04 15:48:19 EST
This is fixed in mkinitrd-6.0.76, which will be in the next rawhide push. Due to the (invasive) nature of this fix we cannot backport this to F-10.
Comment 3 Hans de Goede 2009-02-10 04:57:07 EST
*** Bug 481761 has been marked as a duplicate of this bug. ***
Comment 4 Trevor Christian 2009-02-25 22:20:39 EST
What does this mean for F10 users suffering from this issue?
Comment 5 Jesse Brandeburg 2009-03-03 14:47:42 EST
if you're having this issue on F10, I got around it with an update to my /etc/fstab

I am running a 2.6.29-rc6 kernel (davem's net-next) and was having fedora kernels boot okay but my kernel.org kernsls would not boot.

I changed my /etc/fstab to directly reference the 
/dev/mapper/VolGroup00-LogVol00 / ext3 defaults 1 1

so it was:
UUID=foo      / ext3 defaults 1 1
and i changed it to the above

ran
mkinitrd -f /boot/initrd-2.6.29-rc6.img 2.6.29-rc6

then the mkinitrd files when extracted looked pretty much the same.

Hope this helps someone.
Comment 6 Jesse Brandeburg 2009-03-03 14:52:31 EST
you may also have to change your root= line in /etc/grub.conf for the new kernel
Comment 7 Milan Broz 2009-04-23 04:04:06 EDT
*** Bug 497246 has been marked as a duplicate of this bug. ***
Comment 8 Gerry Reno 2009-04-23 11:09:45 EDT
I tried the workaround that Jesse listed with changing from UUID to /dev/mapper/... style in /etc/fstab and it helps.  But what is going to fix this up on all the machines where this has started to happen where the blkid shows that the /dev/mapper/... device and the /dev/dm-N device have the same UUID?  I want to get all these machines back to working.  What package will correct this?
Comment 9 Milan Broz 2009-04-24 02:53:18 EDT
*** Bug 497259 has been marked as a duplicate of this bug. ***
Comment 10 Milan Broz 2009-04-24 03:59:48 EDT
Just a little bit more explanation (for the closed bug 497246 and bug 497259),

I think that the fstab issue was just consequence of changing UUID in boot line and propagated into fstab.

The dm-X names are internal kernel device names, basically X is minor number allocated for that device. Thus this device name differ between system boots, so userspace never should use dm-X names directly.
(But you can see that name in /sys/block structure - this is internal kernel view.)

Device-mapper still maintains its own nodes in /dev/mapper/ and symlinks according  to VG & LV names.

Unfortunatelly, udev rule create nodes (according to udev event) for all block devices, it creates /dev/dm-X too.
(But I am afraid we cannot simple disable that rule.)

So you can see the same device with /dev/dm-X and /dev/mapper/VG--LV.

(I hope that DM will use udev in Fedora12 for /dev/ creation, but it is not importnant here.)

The question is, which programs during update prefers /dev/dm-X devices (which is wrong).

Here is bug for mkinird, but isn't there still some update mechanism, which modifies /etc/fstab directly, or it was just consequence of this mkinitrd problem?
Comment 11 Hans de Goede 2009-04-24 04:14:25 EDT
(In reply to comment #10)
> Here is bug for mkinird, but isn't there still some update mechanism, which
> modifies /etc/fstab directly, or it was just consequence of this mkinitrd
> problem?  

You are right /dev/dm-# device numbering can change (*) and should not be
used, however sometimes it is used in /etc/fstab (don't know how it ends up there), this bug and the fix for it, is to make mkinitrd work correctly
when a filesystem's device is specified as /dev/dm-# in fstab *as long as
the device numbering does not change*

*) but usually wont unless you make configuration changes to the system
Comment 12 Milan Broz 2009-04-24 04:23:40 EDT
(In reply to comment #11)
> *) but usually wont unless you make configuration changes to the system  

just create two VGs and activate it in swapped order...
Comment 13 Gerry Reno 2009-04-24 11:05:37 EDT
(In reply to comment #10)

> Unfortunatelly, udev rule create nodes (according to udev event) for all block
> devices, it creates /dev/dm-X too.
> (But I am afraid we cannot simple disable that rule.)
> 

So if this is a udev rule then put out some update that will put new rules into effect that prevent this from happening.  We have inhouse scripts that parse outputs of commands and now those scripts break because they pick up devices like /dev/dm-N and these are meaningless.  Parsing blkid output by UUID yields non-unique result.  You get back two devices with same UUID.  This is wrong.  UUID must be unique.
Comment 14 Alexander Vasiljev 2009-05-26 05:19:56 EDT
Hello.

It seems I got the same issue after upgrading to 2.6.27.24-170.2.68.fc10.i686
grub.conf:
kernel /vmlinuz-2.6.27.24-170.2.68.fc10.i686 ro root=/dev/dm-0
fstab:
/dev/dm-0       /       ext3    defaults        1       1

while booting:

unable to access resume device (/dev/dm-1)
Creating root device
mounting root filesystem
mount: could not find filesystem '/dev/root'

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