livecd-tools-028-1.fc12.x86_64 dracut-002-[3-5]*.f12.noarch September 23rd, 2009 nightly LiveCD gets stuck here. Boot with "quiet rhgb" removed and add "rdinitdebug" within KVM with emulated ISO. + [ -n -a -n /LiveOS/overlay-fedora-livecd--i686-200909231707- ] + dd if=/dev/null of=/overlay bs=1024 count=1 seek=524288 + losetup /dev/loop4 /overlay + blockdev --getsize /dev/loop3 + dmsetup create live-rw + echo 0 6291456 snapshot /dev/loop3 /dev/loop4 p 8 echo 0 `blockdev --getsize $BASE_LOOPDEV` snapshot $BASE_LOOPDEV $OVERLAY_LOOPDEV p 8 | dmsetup create live-rw harald suspects that dmsetup might not be working anymore? Warren's last working LiveCD was rawhide September 21st. lvm2-2.02.52-3.fc12 ------------------- * Mon Sep 21 2009 Peter Rajnoha <prajnoha> - 2.02.52-3 - Enable udev synchronisation code. - Install default udev rules for device-mapper and LVM2. - Add BuildRequires: libudev-devel. - Add Requires: libudev (to check udev is running). - Add Requires: util-linux-ng (blkid used in udev rules). Might not be related, but this is the only mention of device-mapper in %changelog after the 21st. device-mapper and kernel did not change since then.
lvm seems to be broken in dracut, see also bug 525015
Please test http://koji.fedoraproject.org/koji/taskinfo?taskID=1702230
That's the long-overdue RPM to enable full udev support. Can someone point us to the sequence of lvm/dm commands being run here and whether the normal udev rules are in place with udev running or not?
dracut-002-7.gitb9c4654a.fc12 has all rules files, shared libs and the dmeventd and is supposed to fix this.
Fingers crossed it works now... I've located the source, so if not, we can attempt to isolate and reproduce problems outside the dracut environment.
I put dracut-002-7.gitb9c4654a.fc12 into a livecd and it boots in KVM successfully. Will try LiveUSB with tomorrow's nightly live image.
should block Beta, not just final release. will test tomorrow myself too. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Well, when using those new device-mapper/lvm2 packages with udev synchronisation enabled (and using kernels >= 2.6.31), then dmsetup/lvm2 process expects the notification after device resume/rename/remove and waits for it! (so we're sure that all udev processing is finished and we can continue with dmsetup/lvm2 command processing) You can disable this by using "--noudevsync" option (in dmsetup as well as LVM2 commands). There's also a new setting in lvm.conf called udev_sync with which you can enable/disable this for LVM2 globally. But when you decide to use udev synchronisation, you must include the logic that is in 95-dm-notify.rules udev rules into dracut (those rules are part of device-mapper package)! This one unlocks the waiting process. It's just this rule that's most important: ENV{DM_COOKIE}=="?*", RUN+="$env{DM_SBIN_PATH}/dmsetup udevcomplete $env{DM_COOKIE}" (...change the DM_SBIN_PATH to where you have dmsetup binary installed..) This synchronisation is automatically turned off for older kernels < 2.6.31, because we do not provide support for important DM_COOKIE env var within udev events there. (..it is also turned off automatically when we detect that udev is not running, but that's just for complete information :))
(DM_COOKIE env var is sent from kernel directly, so no need for any extra rules to get this one)
this was changed again, lvm and dracut both being reverted: warren and I will test and confirm 20090925 rawhide live images boot, and close the bug if so. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
all reports say 20090925+ builds work, so closing this. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers