Description of problem: During boot in a system with the root partition in a LUKS volume, the password to unlock the LUKS volume is requested multiple times even after the correct password is given. The extra password requests can be skipped by pressing CTRL+C or just pressing ENTER until it stops asking for the password. After this, the system will boot correctly. The storage layout is as follows: sda1 (ext4, /boot) sda2 (LUKS) sda2 > LVM sda2 > LVM > lv1 (BtrFS, /root) sda2 > LVM > lv2 (swap) Just in case the above is not clear, I'll describe it in words: The sda disk is divided in two partition: - sda1 is ext4 and is mounted at /boot; - sda2 is LUKS encrypted. Inside the LUKS volume is a LVM volume. The LVM volume is divided in two logical volumes: - lv1 is BtrFS and is mounted at /; - lv2 is swap. Version-Release number of selected component (if applicable): Mageia 4 beta 2 installed from boot-nonfree.iso for AMD64. How reproducible: Always. Steps to Reproduce: 1. Install using boot-nonfree.iso for AMD64. 2. layout the file systems as described above. 3. Boot after installation. 6. Notice the first "Password (/dev/sda2):" prompt. 4. Enter the correct password to unlock the LUKS volume. 5. Notice the "Device crypt_sda2 already exists." message. 7. Notice the second "Password (/dev/sda2):" prompt. 8. Enter anything until it stops asking for the password (or just press CTRL+C). 9. Systems boot correctly. Reproducible: Steps to Reproduce:
Created attachment 4616 [details] Screen shot of repeated password prompts at boot.
Confirming -the same even on a different setup. Maybe it affects everywhere LUKS is used? Also here the WORKAROUND is to give the key twice, then press Ctrl-C. (Works both in graphical mode and safe boot) The setup in my case: I did a fresh install, but reused partitions set up by the former mga2 install: /boot is a separate 120MB ext4, Rest of the disk is LUKS on sda5 partition (and the response in my case is "crypt_sda2 already exists", on that LVM, and there /, /home, swap Except from this strange unlock problem, the installer handled the reuse of partitions perfectly - good work there :)
Priority: Normal => HighCC: (none) => fri
Forgot to say this is installed using mga4b2-64bit DVD iso.
(btw is this a dracut job ?)
CC: (none) => mageia, thierry.vignaud, tmbComponent: Installer => RPM Packages
When i on another already existing cauldron system made an encrypted volume in an existing LVM, set a mount point in a folder under /mnt, and rebooted, it only ask once.
(In reply to Morgan Leijström from comment #5) > When i on another already existing cauldron system made an encrypted volume > in an existing LVM, set a mount point in a folder under /mnt, and rebooted, > it only ask once. This might be due to not rebuilding initrd. It really depends on the partition mountpoint as to whether it's handled by dracut. There could certainly be a problem in which /etc/crypttab in the initrd is over populated with partitions it doesn't strictly need (i.e. / and /usr). In this case it would be interesting to see if /etc/crypttab has several duplicate lines or not in the initrd... but I suspect that actually dracut is seeing multiple partitions stacked up on the same base and treating them all independently. I'll try and recreate the layout/problem in a VM and see if I can poke further.
Thanks Colin. If you want i can send mine, if you tell how to get the /etc/crypttab used in the initrd.
I managed to reproduce this and after a bit of digging found the problem (or rather three related problems) that was causing it. I have two patches that independently correct it and at least one is definitely valid. I've applied that one in our package and sent both upstream for review. Once the new dracut package is pushed (we're in freeze so I cannot do it immediately) can you please test to make sure it works. If you want to test immediately, you can do the following (as root): curl "http://svnweb.mageia.org/packages/cauldron/dracut/current/SOURCES/0518-crypt-Prevent-asking-for-password-multiple-times-if-.patch?revision=560876&view=co&pathrev=560876" | patch /usr/lib/dracut/modules.d/90crypt/cryptroot-ask.sh and then run: dracut -f and reboot. If that works properly for you, please mark the bug as solved! Cheers!
Status: NEW => ASSIGNEDAssignee: bugsquad => mageia
Thank you Colin! That instruction works for me :)
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
After applying the patch the password is only asked once and the system boots correctly but during boot two errors messages are shown that where not shown before the patch. First error message is shown once before the password prompt and once after the password is entered: "/usr/sbin/cryptroot-ask : line 28: getargbool: command not found" The offending line is: "if [ -f /etc/crypttab ] && getargbool 1 rd.luks.crypttab -d -n rd_NO_CRYPTTAB; then" Maybe this error should be fixed before closing this bug as resolved. Second error message is shown by systemd: "[FAILED] Failed to start Cryptography Setup for crypt_sda2 See 'systemctl status systemd-cryptsetup@crypt_sda2.service' for details. [DEPEND] Dependency failed for Encrypted Volumes." Here is the output of some commands to help debug the issue. # systemctl status systemd-cryptsetup@crypt_sda2.service systemd-cryptsetup@crypt_sda2.service - Cryptography Setup for crypt_sda2 Loaded: loaded (/etc/crypttab) Active: activating (start) since Sex 2013-12-27 00:09:19 WET; 5min ago Docs: man:systemd-cryptsetup@.service(8) man:crypttab(5) Main PID: 1074 (systemd-cryptse) CGroup: /system.slice/system-systemd\x2dcryptsetup.slice/systemd-cryptsetup@crypt_sda2.service ââ1074 /usr/lib/systemd/systemd-cryptsetup attach crypt_sda2 /dev/disk/by-uuid/46c97b1d-22d9-4b0c-9ab8-aa946e917c7a Dez 27 00:09:19 localhost systemd[1]: Starting Cryptography Setup for crypt_sda2... # cat /etc/crypttab crypt_sda2 UUID=46c97b1d-22d9-4b0c-9ab8-aa946e917c7a # ls /dev/mapper/ control luks-46c97b1d-22d9-4b0c-9ab8-aa946e917c7a@ vg--mga-root@ vg--mga-swap@ The above /etc/crypttab was unchanged since the installation so there may be an issue in the installer that names luks devices as crypt_* instead of luks-*. Changing /etc/crypttab to "luks-46c97b1d-22d9-4b0c-9ab8-aa946e917c7a UUID=46c97b1d-22d9-4b0c-9ab8-aa946e917c7a" solves the second error.
First problem: Ahh yes, thanks for pointing that our. Fix is simple, will sort that now. As for the second problem, This is interesting and I'll take a look... it would seem tho', that your original crypttab was not copied to the initrd and thus the default name (luks-46c97b1d-22d9-4b0c-9ab8-aa946e917c7a) was used in the initrd and thus the crypt_sda2 name was not used thereafter. This could be related to the fact that the getargbool problem previously mentioned returns false and thus crypttab is not parsed properly. Can you confirm with the (now updated) patch available here: http://svnweb.mageia.org/packages/cauldron/dracut/current/SOURCES/0518-crypt-Prevent-asking-for-password-multiple-times-if-.patch?revision=560954&view=co&pathrev=560954 First, revert the previous patch: curl "http://svnweb.mageia.org/packages/cauldron/dracut/current/SOURCES/0518-crypt-Prevent-asking-for-password-multiple-times-if-.patch?revision=560876&view=co&pathrev=560876" | patch -R /usr/lib/dracut/modules.d/90crypt/cryptroot-ask.sh then apply the new one from the above link, make sure the crypttab is as before, regenerate initrd and reboot and confirm all is well?
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
CC: thierry.vignaud => (none)
The new patch works correctly. All issues mentioned are resolved. I've reverted the /etc/crypttab to the original content, reverted the previous patch, applied the new patch, and rerun dracut -f. The system boots correctly, the password prompt behaves correctly, and the two errors mentioned in https://bugs.mageia.org/show_bug.cgi?id=11992#c10 are gone. Great work, thanks. Will mark the bug as resolved.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED