Two luks password prompt

Ask Fedora
1

I’ve installed fedora 31 with full disk encryption with custom partition size.

If I type right luks password all partions decrypted without issue. But if I type wrong passwod I have to type root and swap separately and for home after system login. I’m not sure what was wrong but I googled didn’t found any solutions works for me.

disk list:
nvme0n1 259:0 0 238,5G 0 disk
├─nvme0n1p1 259:1 0 600M 0 part /boot/efi
├─nvme0n1p2 259:2 0 1G 0 part /boot
└─nvme0n1p3 259:3 0 236,9G 0 part
├─fedora-root 253:0 0 20G 0 lvm
│ └─luks-xxx 0 20G 0 crypt /
├─fedora-swap 253:1 0 8G 0 lvm
│ └─luks-xxx 0 8G 0 crypt [SWAP]
├─fedora-var 253:4 0 8,9G 0 lvm
│ └─luks-xxx 0 8,9G 0 crypt /var
└─fedora-home 253:5 0 200G 0 lvm
└─luks-xxxx 0 200G 0 crypt /home
indent preformatted text by 4 spaces

GRUB_TIMEOUT=7
GRUB_DISTRIBUTOR=“$(sed ‘s, release .*$,g’ /etc/system-release)”
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT=“console”
GRUB_CMDLINE_LINUX=“resume=/dev/mapper/luks-xxx rd.lvm.lv=fedora/root rd.luks.uuid=luks-xxx rd.lvm.lv=fedora/swap rd.luks.uuid=luks-xxx rhgb quiet”
GRUB_DISABLE_RECOVERY=“true”
GRUB_ENABLE_BLSCFG=true

2

That’s just how it works.
When you’re doing a graphical boot and it’s time to mount encrypted partitions, systemd-ask-password-plymouth.service takes over and intercepts the passphrase requests. If the first attempt is successful and all of the partitions are encrypted with the same passphrase, you will only see one prompt, as the response is cached and it is re-entered successively. If you type the wrong passphrase, or if you have multiple passphrases for different partitions (or if you are not using plymouth) you will have to unlock them manually one by one.

2 Likes
3

Are you sure?

I installed same way like my older system but systemd-analyze isn’t same. systemd-cryptsetup listed just one and didn’t have problem like new laptop.

here is older system:

20.830s plymouth-quit-wait.service                                             >
20.100s dracut-initqueue.service                                               >
12.395s systemd-cryptsetup@luks\x2d3a756f06\x2dd98f\x2d4adf\x2dbca2\x2d554f50f1>
 6.184s fwupd.service                                                          >
 5.030s bolt.service                                                           >
  856ms lvm2-monitor.service                                                   >
  702ms systemd-logind.service

and new:

34.274s dracut-initqueue.service
33.409s systemd-cryptsetup@luks\x2ddf22c300\x2de3c7\x2d45f8\x2d8572\x2d43b18e6bcfe6.service
31.320s systemd-cryptsetup@luks\x2dcf91f0b3\x2def00\x2d4fd0\x2d9251\x2d3a46a5cea90e.service
4.752s systemd-cryptsetup@luks\x2d95a09992\x2df0c4\x2d47b5\x2d8369\x2d24af7490cd3a.service
3.559s plymouth-quit-wait.service
2.578s systemd-cryptsetup@luks\x2d6d3c4b11\x2dc0dc\x2d4ce1\x2db174\x2d87c9c7270a03.service
1.619s systemd-udev-settle.service
1.150s systemd-logind.service

as you can see all partions luks decrypt individually.

here is detailed post: (not my post but I have same issue)

4

I dare say I am. That said, I don’t think I’ve ever used the default partitioning scheme or lvm, except for some test days and I don’t remember what that looked like. But that should be largely irrelevant to how luks passphrases are handled at boot.

My turn to ask: are you sure?
What does lsblk say? How about journalctl -b --no-hostname | grep 'cryptsetup\|password'?

Do you mean that your user password is not accepted when you mistype the luks passphrase on your first attempt and you have to unlock your volumes one by one? If that happens even though all the “necessary” partitions have been mounted, you should file a bug against the component that handles passwords at that point in time.