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.
*** Bug 471729 has been marked as a duplicate of this bug. ***
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.
*** Bug 481761 has been marked as a duplicate of this bug. ***
What does this mean for F10 users suffering from this issue?
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.
you may also have to change your root= line in /etc/grub.conf for the new kernel
*** Bug 497246 has been marked as a duplicate of this bug. ***
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?
*** Bug 497259 has been marked as a duplicate of this bug. ***
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?
(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
(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...
(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.
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'