Bug 538079

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.