Bug 11992 - Password to unlock LUKS volume requested multiple times even after correct password is given and shows error "Device crypt_sda2 already exists".
Summary: Password to unlock LUKS volume requested multiple times even after correct pa...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: High major
Target Milestone: ---
Assignee: Colin Guthrie
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-15 12:15 CET by PC LX
Modified: 2013-12-27 23:09 CET (History)
3 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
Screen shot of repeated password prompts at boot. (13.46 KB, image/png)
2013-12-15 12:18 CET, PC LX
Details

Description PC LX 2013-12-15 12:15:20 CET
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:
Comment 1 PC LX 2013-12-15 12:18:59 CET
Created attachment 4616 [details]
Screen shot of repeated password prompts at boot.
Comment 2 Morgan Leijström 2013-12-16 13:28:12 CET
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 => High
CC: (none) => fri

Comment 3 Morgan Leijström 2013-12-16 13:29:52 CET
Forgot to say this is installed using mga4b2-64bit DVD iso.
Comment 4 Manuel Hiebel 2013-12-22 15:28:22 CET
(btw is this a dracut job ?)

CC: (none) => mageia, thierry.vignaud, tmb
Component: Installer => RPM Packages

Comment 5 Morgan Leijström 2013-12-23 04:24:23 CET
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.
Comment 6 Colin Guthrie 2013-12-23 12:29:10 CET
(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.
Comment 7 Morgan Leijström 2013-12-23 21:42:04 CET
Thanks Colin.
If you want i can send mine, if you tell how to get the /etc/crypttab used in the initrd.
Comment 8 Colin Guthrie 2013-12-26 22:36:29 CET
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!
Colin Guthrie 2013-12-26 22:37:17 CET

Status: NEW => ASSIGNED
Assignee: bugsquad => mageia

Comment 9 Morgan Leijström 2013-12-27 00:10:54 CET
Thank you Colin!
That instruction works for me :)

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

Comment 10 PC LX 2013-12-27 01:55:14 CET
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.
Comment 11 Colin Guthrie 2013-12-27 14:03:16 CET
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 => REOPENED
Resolution: FIXED => (none)

Thierry Vignaud 2013-12-27 15:33:18 CET

CC: thierry.vignaud => (none)

Comment 12 PC LX 2013-12-27 23:09:05 CET
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 => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.