After installing using Mageia-3-beta3-LiveCD-GNOME-en-i586-CD.iso, booting into the installed systems fails to mount the root filesystem. In the emergency shell, after manually running modprobe dm-crypt cryptsetup luksOpen /dev/sda6 crypt_sda6 and then pressing ctrl+d, booting works. Reproducible: Steps to Reproduce:
CC: (none) => thomas.backlundWhiteboard: (none) => 3beta3
Created attachment 3564 [details] sosreport.txt from failed boot
Created attachment 3565 [details] dracut.log /boot is on sda1, / is on the encrypted sda6.
In your initrd do you have a /etc/cmdline.d/90crypt.conf file? If so what are it's contents? If no such file exists (and from the SOS report it looks like it does not), does passing "rd.luks.uuid=luks-a093707c-e7f4-47e9-baf9-ead5614b487c" on the kernel command line allow a smooth boot? Does running dracut on the booted system create a working initrd? (basically an "lsinitrd foo.img | grep cmdline.d" on the resulting file should show you the /etc/cmdline.d/90crypt.conf file) If not then the error is likely in the file: modules.d/90crypt/module-setup.sh Assuming it doesn't work, can you change the line: for_each_host_dev_fs check_crypt || return 1 to instead read: for_each_host_dev_and_slaves_all check_crypt || return 1 And see if that helps? Cheers Col
CC: thomas.backlund => tmb
(In reply to Colin Guthrie from comment #3) > In your initrd do you have a /etc/cmdline.d/90crypt.conf file? > > If so what are it's contents? File is not included in the initrd. > If no such file exists (and from the SOS report it looks like it does not), > does passing "rd.luks.uuid=luks-a093707c-e7f4-47e9-baf9-ead5614b487c" on the > kernel command line allow a smooth boot? Yes. > Does running dracut on the booted system create a working initrd? (basically > an "lsinitrd foo.img | grep cmdline.d" on the resulting file should show you > the /etc/cmdline.d/90crypt.conf file) It does include it, but it fails to boot. First it asks for the passphrase, and opens the encrypted block device. Then it asks for the passprhase again, and no matter what you enter, reports back that /dev/sda6 already exists, so you have to press enter 5 times, after which it reports "Wrong password" Then when it tries to mount the root filesystem, it fails with dracut Warning: "/dev/mapper/luks-a09..." does not exist The /dev/mapper directory only contains the control character device and the symlink crypt_sda6 -> ../dm-0. > If not then the error is likely in the file: > modules.d/90crypt/module-setup.sh > > Assuming it doesn't work, can you change the line: > for_each_host_dev_fs check_crypt || return 1 > to instead read: > for_each_host_dev_and_slaves_all check_crypt || return 1 Not sure if you still want this test, as it does include the 90crypt.conf file, when run from the installed system.
Still present in latest Live iso images. [dave@x2s Mageia-3-beta3-LiveDVD-GNOME-i586-DVD]$ cat DATE.txt Mon Mar 4 22:30:00 CET 2013
Priority: Normal => release_blocker
Blocks: (none) => 8337
Summary: dracut won't mount encrypted root filesystem. => dracut won't mount encrypted root filesystem after install from live iso
CC: (none) => nelg
Whiteboard: 3beta3 => 3beta4
Still present. [dave@x2s Mageia-3-beta4-LiveCD-GNOME-en-i586-CD]$ cat DATE.txt Fri Apr 5 14:00:00 CEST 2013 Making the change suggested in comment 3 before installing to the hard drive has no effect.
Created attachment 3698 [details] Output of dracut --debug while chrooted into /mnt/install from live
Output from udevadm info --query=property --name=/dev/mapper/crypt_sda5 while in a chroot from the live iso ... DEVNAME=/dev/dm-0 DEVPATH=/devices/virtual/block/dm-0 DEVTYPE=disk MAJOR=252 MINOR=0 SUBSYSTEM=block The following additional lines are output if run while booted into the installed system ... DM_NAME=crypt_sda5 DM_SUSPENDED=0 DM_UDEV_PRIMARY_SOURCE_FLAG=1 DM_UDEV_RULES_VSN=2 DM_UUID=CRYPT-LUKS1-2a92bc9840ea41088d577c734f4076af-crypt_sda5 ID_FS_LABEL=crypt_sda5 ID_FS_LABEL_ENC=crypt_sda5 ID_FS_TYPE=ext4 ID_FS_USAGE=filesystem ID_FS_UUID=49fba05c-9d3d-4987-95a5-d974fba09379 ID_FS_UUID_ENC=49fba05c-9d3d-4987-95a5-d974fba09379 ID_FS_VERSION=1.0 TAGS=:systemd: UDISKS_PRESENTATION_NOPOLICY=1 USEC_INITIALIZED=9574624 So the problem is clear, in that udev is not returning the needed info when in a chroot environment.
Running dracut -f from the booted system does fix the problem now.
CC: (none) => mageiaAssignee: mageia => thierry.vignaudSource RPM: dracut-025-5.mga3.src.rpm => drakxtools-15.33-1.mga3.src.rpm
Created attachment 3701 [details] Patch to bind mount /run in the chroot Figured it out. /run must be bind mounted in the chroot, for udev to get all of the information. With the attached patch applied, it works.
Keywords: (none) => PATCH
Colin, do you agree?
Depending on the context, it might make sense just to mount /run as tmpfs and then bindmount /run/udev and /run/initramfs (or simply mkdir the later). This should be sufficient and won't clobber things like pidfiles for any services which may have been started on the live media itself. I think you do pretty much this same trick in drakx-in-chroot Theirry, so might make sense to mirror the behaviour?
(In reply to Colin Guthrie from comment #12) > Depending on the context, it might make sense just to mount /run as tmpfs > and then bindmount /run/udev and /run/initramfs (or simply mkdir the later). > This should be sufficient and won't clobber things like pidfiles for any > services which may have been started on the live media itself. I think you > do pretty much this same trick in drakx-in-chroot Theirry, so might make > sense to mirror the behaviour? Since /run is a tmpfs, it doesn't survive reboot anyway. In the install I did with the patch applied, the /run directory is empty.
Fixed
Status: NEW => RESOLVEDResolution: (none) => FIXED