Created attachment 457789 [details] screenshot of frozen boot with plymouth:debug enabled Description of problem: I installed minimal installation from Fedora 14 DVD x86_64. I used a custom layout: /dev/vda1 500MB /boot /dev/vda2 7GB / (encrypted) Therefore I used dm-crypt and LUKS, but did not use LVM. Anaconda installed 196 packages. After boot the system asks for password and then waits indefinitely. When I do the same installation, but with Use whole disk option (default partition layout, meaning using encrypted partitions *with* LVM), anaconda installs 200 packages and the system boots just fine. After comparing install.log from these two installations I found out that following packages were installed in the default partitioning case but were not installed in my custom partitioning case: device-mapper-event-libs-1.02.54-3.fc14.x86_64 device-mapper-event-1.02.54-3.fc14.x86_64 lvm2-libs-2.02.73-3.fc14.x86_64 lvm2-2.02.73-3.fc14.x86_64 I suspect that the device-mapper packages are exactly those packages that are missing in my system to be able to boot successfully. Version-Release number of selected component (if applicable): anaconda 14.22 Fedora 14 How reproducible: always Steps to Reproduce: 1. Boot Fedora 14 2. Do custom layout - /boot and encrypted / without LVM 3. Try to boot Actual results: system doesn't boot Expected results: system boots
Created attachment 457790 [details] install.log with default partitioning
Created attachment 457791 [details] install.log with custom partitioning
Created attachment 457792 [details] anaconda-ks.cfg with default partitioning
Created attachment 457793 [details] anaconda-ks.cfg with custom partitioning
The initial failure here is a dracut boot failure. The problem may end up being the result of the packages included during install ... but moving this over to dracut for further review.
Created attachment 457797 [details] boot with rdshell rdinitdebug arguments
Created attachment 457811 [details] boot with "rdshell rdinitdebug plymouth:debug" arguments
(In reply to comment #7) > Created attachment 457811 [details] > boot with "rdshell rdinitdebug plymouth:debug" arguments I'm testing while booting with dracut keyword "rdbreak=pre-trigger". Once booted into the shell, it seems that the 'cryptsetup luksOpen ...' is hanging ... pre-trigger:/# modprobe -a virtio_pci pre-trigger:/# UUID=$(cryptsetup luksUUID /dev/vda2) pre-trigger:/# cryptsetup --verbose --debug luksOpen /dev/vda2 luks-$UUID # cryptsetup 1.1.3 processing "cryptsetup --verbose --debug luksOpen /dev/vda2 luks-395172d0-405a-4b64-a3aa-6b3ce5268dac" # Locking memory. # Allocating crypt device /dev/vda2 context. # Trying to open and read device /dev/vda2. # Initialising device-mapper backend, UDEV is enabled. # Timeout set to 0 miliseconds. # Password retry count set to 3. # Iteration time set to 1000 miliseconds. # Password verification disabled. # Trying to load LUKS1 crypt type from device /dev/vda2. # Initializing crypto backend (using secure memory). # Reading LUKS header of size 1024 from device /dev/vda2 # Activating volume luks-395172d0-405a-4b64-a3aa-6b3ce5268dac [keyslot -1] using [none] passphrase. # dm status luks-395172d0-405a-4b64-a3aa-6b3ce5268dac OF [16384] Enter passphrase for /dev/vda2: # Trying to open key slot 0 [3]. # Reading key slot 0 area. # DM-UUID is CRYPT-TEMP-temporary-cryptsetup-115 # Udev cookie 0xd4d0876 (semid 0) created # Udev cookie 0xd4d0876 (semid 0) incremented # Udev cookie 0xd4d0876 (semid 0) incremented # Udev cookie 0xd4d0876 (semid 0) assigned to dm_task type 0 with flags 0xe # dm create temporary-cryptsetup-115 CRYPT-TEMP-temporary-cryptsetup-115 OF [16384] # temporary-cryptsetup-115: Stacking NODE_ADD (253,0) 0:6 0660 # dm reload temporary-cryptsetup-115 OF [16384] [ 43.302166] padlock: VIA PadLock not detected. [ 43.311428] Intel AES-NI instructions are not detected. # dm resume temporary-cryptsetup-115 OF [16384] # temporary-cryptsetup-115: Stacking NODE_READ_AHEAD 256 (flags=1) # Udev cookie 0xd4d0876 (semid 0) decremented # Udev cookie 0xd4d0876 (semid 0): Waiting for zero <hangs here> Possible UDEV problem?
Harald indicated on IRC that it's likely due to the missing packages Kamil noted when filing this bug. The required, but missing, packages are device-mapper-event-libs, device-mapper-event. The next question is what is the proper way to ensure these packages are installed? Some ideas to get discussion flowing ... 1) Hard-code the required packages in anaconda 2) Update comps.xml to ensure that device-mapper-event[-libs] is included in @core 3) Add a package %requires device-mapper-event-libs to some package that is already included in @core? I believe maintainer feedback will be needed to determine the appropriate next step.
Well, it cannot work without installed dm udev rules. IMHO either libdevmapper should detect that something is broken and not announce udev support (then it will not use cookie and fallback to old mode) or someone must install these rules with the base system always. Of course I can add dependence to cryptsetup but the problem is generic - any other application using devmapper will deadlock here the same way wihout udev rules installed.
(In reply to comment #10) > Well, it cannot work without installed dm udev rules. What rules are needed in the dracut initramfs? How do we get these rules in there. When installing the @default package set, it seems these rules are available. Is something detecting, or is the presence of a package, allowing the rules to be created?
So are we saying when dracut installs the device-mapper package into the initramfs it is losing some of its essential files?
OK, I've reproduced this problem - device-mapper udev rules are missing in initrd. Whatever uses libdevmapper and expects the udev support to be working fine, it needs to add all the rules found in device-mapper package + dmsetup command itself! Missing rules are 10-dm.rules, 13-dm-disk.rules and the most important one - 95-dm-notify.rules. (btw this is also the reason why we have dependency "device-mapper-libs requires device-mapper)
(iow device-mapper udev rules are needed even for standalone cryptsetup, multipath... anything using udev-enabled libdevmapper)
Based on Peter's comment, I think we need guidance from Harald to proceed?
Patches needed for dracut: http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut/dracut;a=commitdiff;h=9c7f67a94d7cb87d846391b5bec72213b77ddb3e http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut/dracut;a=commitdiff;h=06f91665dfc379b051ad4eb18bdddd7bfb9c23e9 and diff --git a/modules.d/90dm/install b/modules.d/90dm/install index 28e53b3..b2080e5 100755 --- a/modules.d/90dm/install +++ b/modules.d/90dm/install @@ -7,5 +7,5 @@ modinfo -k $kernel dm_mod >/dev/null 2>&1 && \ inst dmsetup -inst dmeventd +type -P dmeventd >/dev/null && dracut_install dmeventd inst_rules 10-dm.rules 95-dm-notify.rules
I can confirm that with the patches listed in comment#16, I was able to rebuild the initrd and get a working system. If/when these patches land in a dracut package in F14, I'll be happy to add this issue to http://fedoraproject.org/wiki/Common_F14_bugs. In the meantime, are there any workarounds that might allow affected users to boot their systems?
(In reply to comment #17) > I can confirm that with the patches listed in comment#16, I was able to rebuild > the initrd and get a working system. > > If/when these patches land in a dracut package in F14, I'll be happy to add > this issue to http://fedoraproject.org/wiki/Common_F14_bugs. In the meantime, > are there any workarounds that might allow affected users to boot their > systems? affected users could install lvm2 :)
dracut-006-6.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/dracut-006-6.fc14
dracut-006-6.fc14 has been pushed to the Fedora 14 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-006-6.fc14
dracut-006-6.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.