Created attachment 369897 [details] console output from hung dracut boot Patched up my rawhide KVM guest today and it installed kernel-2.6.32-0.48.rc7.git1.fc13.x86_64. When booting, dracut gets to the point where it's bringing up the root LVM volume group and then just hangs. When I rebuilt the initrd with mkinitrd instead, it boots all the way up without any issue. Relevant package versions: dracut-002-22.git200e5914.fc13.noarch mkinitrd-6.0.93-1.fc12.x86_64 kernel-2.6.32-0.48.rc7.git1.fc13.x86_64
FATAL: Module dm_mod not found.
hmm, maybe compiled in the kernel.. can you boot with: "rdinitdebug" added to the kernel command line?
oh and maybe also "rdudevinfo"
Created attachment 369934 [details] dracut debug output Here's the requested dracut debug output.
And yes...dm_mod appears to be built in.
udevd-work[86]: RUN '$env{DM_SBIN_PATH}/dmsetup udevcomplete $env{DM_COOKIE}' /etc/udev/rules.d/95-dm-notify.rules:12 udevd-work[245]: program '/usr/sbin/dmsetup' not found seems like DM_SBIN_PATH is set incorrectly..
*** Bug 537944 has been marked as a duplicate of this bug. ***
still a problem?
Nope, not on F13.
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
My Fedora upgrade (11->13) failed also because LVM based root-fs could not be found. This occurred first with preupgrade, and then with "yum upgrade". After adding kernel command line parameter "rdshell", I saw the directory /dev/mapper didn't have any volumes. But running "lvm vgchange -a y" initialized them, and booting continued fine. So it seems like dracut isn't initializing LVM before attempting to mount root-fs. Is there a way the feed commands for dracut to be executed before mount?
(In reply to comment #11) > My Fedora upgrade (11->13) failed also because LVM based root-fs could not be > found. This occurred first with preupgrade, and then with "yum upgrade". > After adding kernel command line parameter "rdshell", I saw the directory > /dev/mapper didn't have any volumes. But running "lvm vgchange -a y" > initialized them, and booting continued fine. > So it seems like dracut isn't initializing LVM before attempting to mount > root-fs. > Is there a way the feed commands for dracut to be executed before mount? Does it help to recreate the initramfs image after you managed to boot? # dracut -f If not, what is your kernel command line?
(In reply to comment #12) > Does it help to recreate the initramfs image after you managed to boot? > # dracut -f No. The image is created and its size is different, but booting still fails. > If not, what is your kernel command line? Kernel command line: ro root=UUID=76cf1bb2-2050-4e4f-a336-ad9b9debc181 SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=fi-latin1 rdshell The result is the same if I boot with only ro & root parameters.
(In reply to comment #13) > (In reply to comment #12) > > Does it help to recreate the initramfs image after you managed to boot? > > # dracut -f > > No. The image is created and its size is different, but booting still > fails. > > > If not, what is your kernel command line? > > Kernel command line: ro root=UUID=76cf1bb2-2050-4e4f-a336-ad9b9debc181 > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=fi-latin1 rdshell > > The result is the same if I boot with only ro & root parameters. what is the output of: # for i in /dev/sd*; do echo $i; udevadm info --query=all --name=$i;done # dmsetup ls --tree
Created attachment 438982 [details] udevadm info and dmsetup ls output
E: ID_FS_TYPE=LVM1_member oh... LVM1 !!! not LVM2! edit: /usr/share/dracut/modules.d/90lvm/64-lvm.rules change "LVM2_member" to "LVM?_member" , recreate the dracut image with: # dracut -f and it might work. Or convert your LVM1 to version 2, if that is possible.
Yes, now it works! I didn't convert to LVM2 yet, but only changed the "LVM?_member" in 64-lvm.rules. Instead of giving up after last sr line, I now get; sr 1:0:1:0: Attached scsi generic sg2 type 5 dracut: Scanning devices sda2 for LVM volume groups dracut: Reading all physical volumes. This may take a while... dracut: Found volume group "Volume00" using metadata type lvm1 dracut: 7 logical volume(s) in volume group "Volume00" now active kjournald starting. Commit interval 5 seconds EXT3-fs (dm-0): mounted filesystem with ordered data mode dracut: Mounted root filesystem /dev/mapper/Volume00-LogVol00
dracut-005-4.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/dracut-005-4.fc13
dracut-005-4.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/dracut-005-4.fc12
dracut-005-4.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update dracut'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/dracut-005-4.fc12
Just like to report that I encountered this problem during a Fedora 14 Beta install. Follwed instructions as per comment 16.. edit: /usr/share/dracut/modules.d/90lvm/64-lvm.rules change "LVM2_member" to "LVM?_member" , recreate the dracut image with: # dracut -f and all was well again.. Though I was rather annoyed by the time I found this.. Situation was LVM root on an md raid (mirrored between sd[ab]1) /boot on md raid sd[ab]0 Nothing I've not done in the past.. I'm not sure exactly how to retest the installer before it goes to release...?? Cheers Richard
dracut-005-5.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
dracut-005-5.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.