Issues with booting encrypted root partition after latest system update (2022-12-21)

Support
,
1

Brief setup overview:

root partition, including /boot, is encrypted.

At boot, right after BIOS messages, I am asked to enter the password to decrypt. This did not break at all.

After system update (relevant pacman log: [2022-12-21T15:13:16+0100] [PACMAN] starting full system upgrade[2022-12-21T15 - Pastebin.com ), Manjaro did not boot anymore. The reason was: /dev/mapper/[my_decrypted_disk] did not exist at all. The whole /dev/mapper/ directory was missing and I got dropped into an emergency shell.

The root cause for this was that, for some reason, the “encrypt” hook in the mkinitcpio.conf was missing now. After re-adding this and rebuilding the images while chroot-ed, I managed to restore the ability to boot the system.

However, one problem remains: I have to enter my decryption password twice now.

  1. System starts up
  2. I get asked my decryption password (like before)
  3. I see the grub boot menu (like before)
  4. After booting (any) kernel (6.0 and 6.1 tried), once the encrypt hook is executed, I get a second password prompt for the root partition.
  5. entering it again will boot the system normally

How do I get rid of the second password promt?

current mkinitcpio.conf (comments removed for readability)

MODULES=()
BINARIES=()
FILES=()
HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block encrypt filesystems fsck)

Not sure if relevant, but this is the /etc/crypttab entry for my root partition (there are other, non-boot disks in there):

luks-5deaef3c-c1ae-4367-be30-afa723c79880 UUID=5deaef3c-c1ae-4367-be30-afa723c79880     /crypto_keyfile.bin luks

lsblk:

lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                                             8:0    0 931,5G  0 disk  
└─sda1                                          8:1    0 912,9G  0 part  
  └─Games-big                                 254:1    0 912,9G  0 crypt /run/media/anpan/Games
sdb                                             8:16   0   1,8T  0 disk  
└─sdb1                                          8:17   0   1,8T  0 part  
  └─Games2                                    254:2    0   1,8T  0 crypt /run/media/anpan/Games2
nvme0n1                                       259:0    0 931,5G  0 disk  
├─nvme0n1p1                                   259:1    0   500M  0 part  /boot/efi
└─nvme0n1p2                                   259:2    0   892G  0 part  
  └─luks-5deaef3c-c1ae-4367-be30-afa723c79880 254:0    0   892G  0 crypt /
nvme1n1                                       259:3    0   1,8T  0 disk  
└─nvme1n1p1                                   259:4    0   1,8T  0 part  
  └─WD2TBm2                                   254:3    0   1,8T  0 crypt /run/media/anpan/WD2TBm2

blkid:

/dev/mapper/Games-big: LABEL="Games" UUID="d38bfbfc-f6af-42bd-8675-a2900e3aeb89" BLOCK_SIZE="4096" TYPE="ext4"
/dev/nvme0n1p1: UUID="7A28-4F99" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="1a3099f1-fe42-4a80-b925-a96cacfb7a8f"
/dev/nvme0n1p2: UUID="5deaef3c-c1ae-4367-be30-afa723c79880" TYPE="crypto_LUKS" PARTUUID="d0e18390-aac2-49f8-a340-0c5f82a550d5"
/dev/sdb1: UUID="bca8cb27-6c26-45d9-8312-e383950f2d65" TYPE="crypto_LUKS" PARTUUID="ea328a1b-c28c-4f6c-be9e-5f0606b06cf0"
/dev/mapper/Games2: LABEL="Games2" UUID="1680fc24-943f-4b40-97b5-8c35815121ea" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/luks-5deaef3c-c1ae-4367-be30-afa723c79880: UUID="74008526-3d9a-443c-b148-ba5c87061314" BLOCK_SIZE="4096" TYPE="ext4"
/dev/nvme1n1p1: UUID="4b5fe8d3-0cf3-4258-95ec-2de0e56c811f" TYPE="crypto_LUKS" PARTUUID="2ff75922-3c4c-42c9-9f39-05b890e588e5"
/dev/sda1: UUID="8bb2800f-7e8f-4427-8225-9b834bd59226" TYPE="crypto_LUKS" PARTUUID="bd6fe2c3-cc15-48f8-b1ad-2b24d7ffa82b"
/dev/mapper/WD2TBm2: LABEL="WD2TBm2" UUID="1c4ad788-3b57-46b3-b6b8-539d0e838b98" BLOCK_SIZE="4096" TYPE="ext4"

Not sure if it matters: This system is many years old and migrated between 4 disks and 3 PCs by now.

Any help will be greatly appreciated.

2 Likes
2

:point_up: This is why.

You need to re-add your keyfile in here.

For example,

FILES="/crypto_keyfile.bin"

This is the default filename and location used by the installer.

Then rebuild your initramfs with sudo mkinitcpio -P

My guess is that your customized mkinitcpio.conf was replaced with a vanilla one in the update. You can check for your old one with the appended name mkinitcpio.conf.pacsave

Usually it’s the other way around. Your configured version remains intact, while the new vanilla version takes on the name mkinitcpio.conf.pacnew

You can comment out the entry for your root partition in the crypttab. This is handled by your initramfs. The other entries you can leave as they are (such as home, data, whatever).

4 Likes
3

Thank you, the FILES change helped.

Honestly I don’t know why the root partition is in the crypttab file, I don’t remember ever adding it there. Will try commenting that out that now.

I am also used to config files not simply being overwritten and instead being placed next to the existing one with .pacnew (I see that occasionally in the update log and then manually have a look at the files). Not sure what happened here, because there is neither a .pacsave nor a .pacnew for the mkinitcpio.conf file.

4

I always comment out mine.

The installer automatically generates this entry in your crypttab. It might be for “reference” reasons, so you can gauge what options and names are being used. But it might as well be commented out by default, so that the user understands that “this is not being used, so don’t bother.”

If you want to apply particular LUKS options to your root partition (such as allow-discards) you need to specify this in your loader options (which in the case of Grub, is done in the file /etc/default/grub)

I agree. That shouldn’t have happened. Not sure why this time it did. :person_shrugging:

1 Like
5

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.