Can't disable password prompt for encrypted drive at boot

alteredstate · September 13, 2024, 10:26am

Dear community,

I have two encrypted drives in my system:

drive a is my EndeavourOS installation including my home and the entire OS
drive b is just a data drive

Until a few months or so ago I was asked to enter my password to decrypt “drive a” at boot as desired. Suddenly the system began asking me for the password for “drive b” as well and I can’t figure out why. I want to decrypt “drive b” when I actually need it during my user session so this prompt is useless for me and makes the boot process unnecessarily longer but I can’t seem to convince EndeavourOS to stop asking me about it.

Here is what I’ve found and tried so far:

Drive b is not mentioned in: /etc/crypttab, /etc/fstab, /proc/cmdline, /etc/kernel/cmdline

I’m getting an error message when I just hit enter instead of entering the password for drive b at boot. It refers to systemd-cryptsetup@luks\driveb.service. I can see that service with systemctl but there is no unit file for it. The unit disappears after systemctl reset-failed but reappears after the next boot. I even tried removing /usr/lib/systemd/system-generators/systemd-cryptsetup-generator to no avail.

systemd-cryptsetup@luks\driveb.service
     Loaded: not-found (Reason: Unit systemd-cryptsetup@luks\driveb.service not found.)
     Active: failed (Result: exit-code) since Fri 2024-09-13 12:08:40 CEST; 8min ago
 Invocation: e4b488bad63545d9a51fcf0b529d8e90
   Main PID: 529 (code=exited, status=1/FAILURE)
   Mem peak: 1G
        CPU: 19.948s

Sep 13 12:08:34 val systemd-cryptsetup[529]: Failed to activate with specified passphrase. (Passphrase incorrect?)
Sep 13 12:08:35 val systemd-cryptsetup[529]: Set cipher aes, mode xts-plain64, key size 256 bits for device /dev/sdc1.
Sep 13 12:08:37 val systemd-cryptsetup[529]: Failed to activate with specified passphrase. (Passphrase incorrect?)
Sep 13 12:08:38 val systemd-cryptsetup[529]: Set cipher aes, mode xts-plain64, key size 256 bits for device /dev/sdc1.
Sep 13 12:08:40 val systemd-cryptsetup[529]: Failed to activate with specified passphrase. (Passphrase incorrect?)
Sep 13 12:08:40 val systemd-cryptsetup[529]: Too many attempts to activate; giving up.
Sep 13 12:08:40 val systemd[1]: systemd-cryptsetup@luks\driveb.service: Main process exited, code=exited, status=1/FAILURE
Sep 13 12:08:40 val systemd[1]: systemd-cryptsetup@luks\driveb.service: Failed with result 'exit-code'.
Sep 13 12:08:40 val systemd[1]: Failed to start Cryptography Setup for luks-driveb.
Sep 13 12:08:40 val systemd[1]: systemd-cryptsetup@luks\driveb.service: Consumed 19.948s CPU time, 1G memory peak.

I’m not a C developer but looking at cryptsetup-generator.c it doesn’t seem like it’s getting crypt devices from any other locations than the aforementioned ones. Maybe SYSTEMD_CRYPTTAB is set to something else during boot and that file actually mentions drive b but I couldn’t find any other “crypttab” files with find and even a system-wide grep for the ID didn’t yield any results apart from journal entries.

The systemd unit might be a red herring but I’m not sure. There is no unit file for “drive a” after having removed cryptsetup-generator and decryption at boot still works for it but of course it’s mentioned in the aforementioned files that “drive b” doesn’t appear in.

Happy to try any debug steps or experiments.

Thanks in advance for any suggestions!

dalto · September 13, 2024, 10:38am

Does /etc/crypttab have a keyfile for that second drive listed? If so, did you delete that keyfile?

That is the most common cause of this issue.

alteredstate · September 13, 2024, 11:19am

/etc/crypttab lists a keyfile but that’s for drive a. Here is the entire file:

# <name>               <device>                         <password> <options>
luks-drivea UUID=drivea     /crypto_keyfile.bin luks

manfredlotz · September 13, 2024, 12:46pm

That’s the problem. /etc/crypttab should have a second line with a keyfile for drive b.

alteredstate · September 13, 2024, 1:45pm

Thanks for your suggestions!

I have added a line to /etc/crypttab for drive b with a non-existing keyfile but I’m still getting the password prompt, which is to be expected given the keyfile doesn’t exist. Just to be clear: I don’t want to decrypt the drive at boot. I just don’t want the boot process to try and decrypt it at all. So if I create a keyfile for it and have it decrypted automatically that kind of defeats the purpose of me not wanting to decrypt it.

manfredlotz · September 13, 2024, 4:57pm

If you don’t want to access the disk during boot then remove it from /etc/fstab

2000 · September 13, 2024, 7:44pm

Are you absolutely sure? It would maybe help to see the output of lsblk and sudo blkid as well as the aforementioned files.

Otherwise, there could be some systemd auto-mounting in play:
See https://wiki.archlinux.org/title/Systemd#GPT_partition_automounting and https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#Overview

To prevent automounting, see https://wiki.archlinux.org/title/GPT_fdisk#Prevent_GPT_partition_automounting

alteredstate · September 14, 2024, 10:02am

As per my initial post

Thanks for that idea! I have set the do not automount attribute on my drive but it didn’t resolve the problem unfortunately.

Here are all the files and info you asked for:

gdisk info for the drive and partition

Command (? for help): p
Disk /dev/sdc: 1953525168 sectors, 931.5 GiB
Model: WDC WD10EZEX-08W
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): F184E901-ED8F-4AF1-9DC5-8EF1F0D04862
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      1953525134   931.5 GiB   8300  

Command (? for help): i
Using 1
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: F2BF64D3-B018-4D82-9D13-82BCE8EF92D3
First sector: 2048 (at 1024.0 KiB)
Last sector: 1953525134 (at 931.5 GiB)
Partition size: 1953523087 sectors (931.5 GiB)
Attribute flags: 8000000000000000
Partition name: ''

gparted screenshot of flags

/etc/fstab

cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=8901-DC4B                            /efi      vfat    umask=0077 0 2
/dev/mapper/luks-28ded036-cbcc-4ea1-b4e1-25a9555de0f2 /              ext4    defaults,noatime 0 1
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

For completeness sake, the first file system that’s listed here refers to sda1 not sdc1 the “drive b” I’m talking about.

ls -l /dev/disk/by-uuid/8901-DC4B
lrwxrwxrwx 1 root root 10 Sep 14 11:44 /dev/disk/by-uuid/8901-DC4B -> ../../sda1

/etc/crypttab

cat /etc/crypttab 
# /etc/crypttab: mappings for encrypted partitions.
#
# Each mapped device will be created in /dev/mapper, so your /etc/fstab
# should use the /dev/mapper/<name> paths for encrypted devices.
#
# See crypttab(5) for the supported syntax.
#
# NOTE: Do not list your root (/) partition here, it must be set up
#       beforehand by the initramfs (/etc/mkinitcpio.conf). The same applies
#       to encrypted swap, which should be set up with mkinitcpio-openswap
#       for resume support.
#
# <name>               <device>                         <password> <options>
luks-28ded036-cbcc-4ea1-b4e1-25a9555de0f2 UUID=28ded036-cbcc-4ea1-b4e1-25a9555de0f2     /crypto_keyfile.bin luks

/proc/cmdline

cat /proc/cmdline 
initrd=\600f0b1a47f14a08a960d8b4e97ac812\6.10.9-arch1-2\initrd root=UUID=a9cd9832-fa2d-4f16-998d-29b64fbf604a rw quiet cryptdevice=UUID=28ded036-cbcc-4ea1-b4e1-25a9555de0f2:luks-28ded036-cbcc-4ea1-b4e1-25a9555de0f2 root=/dev/mapper/luks-28ded036-cbcc-4ea1-b4e1-25a9555de0f2 loglevel=3 nowatchdog systemd.machine_id=600f0b1a47f14a08a960d8b4e97ac812

/etc/kernel/cmdline

cat /etc/kernel/cmdline 
root=UUID=a9cd9832-fa2d-4f16-998d-29b64fbf604a rw quiet cryptdevice=UUID=28ded036-cbcc-4ea1-b4e1-25a9555de0f2:luks-28ded036-cbcc-4ea1-b4e1-25a9555de0f2 root=/dev/mapper/luks-28ded036-cbcc-4ea1-b4e1-25a9555de0f2 loglevel=3 nowatchdog

lsblk

lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                                             8:0    0 232.9G  0 disk  
├─sda1                                          8:1    0   512M  0 part  /efi
└─sda2                                          8:2    0 232.4G  0 part  
  └─luks-28ded036-cbcc-4ea1-b4e1-25a9555de0f2 254:0    0 232.4G  0 crypt /
sdb                                             8:16   0 596.2G  0 disk  
└─sdb1                                          8:17   0 596.2G  0 part  
sdc                                             8:32   0 931.5G  0 disk  
└─sdc1                                          8:33   0 931.5G  0 part  
sr0                                            11:0    1  1024M  0 rom   
nvme0n1                                       259:0    0 232.9G  0 disk  
├─nvme0n1p1                                   259:1    0   539M  0 part  
├─nvme0n1p2                                   259:2    0   500M  0 part  
├─nvme0n1p3                                   259:3    0 231.1G  0 part  
└─nvme0n1p4                                   259:4    0   762M  0 part

blkid

blkid
/dev/nvme0n1p3: BLOCK_SIZE="512" UUID="36C82BDDC82B99DF" TYPE="ntfs" PARTUUID="bc3590c8-22bc-11ed-8ce1-782b46d95edf"
/dev/nvme0n1p1: BLOCK_SIZE="512" UUID="680C8BF00C8BB798" TYPE="ntfs" PARTUUID="bc3590c6-22bc-11ed-8ce1-782b46d95edf"
/dev/nvme0n1p4: BLOCK_SIZE="512" UUID="803C003A3C002DAA" TYPE="ntfs" PARTUUID="a5f76424-a933-44b2-8355-1eb5efa85120"
/dev/nvme0n1p2: UUID="5A10-59F6" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="bc3590c7-22bc-11ed-8ce1-782b46d95edf"
/dev/sdb1: BLOCK_SIZE="512" UUID="7876B2A75AA3E12D" TYPE="ntfs" PARTUUID="157747ad-01"
/dev/mapper/luks-28ded036-cbcc-4ea1-b4e1-25a9555de0f2: UUID="a9cd9832-fa2d-4f16-998d-29b64fbf604a" BLOCK_SIZE="4096" TYPE="ext4"
/dev/sdc1: UUID="6ed8cf7b-1fb2-4dad-9648-14adb275e8f7" TYPE="crypto_LUKS" PARTUUID="f2bf64d3-b018-4d82-9d13-82bce8ef92d3"
/dev/sda2: UUID="28ded036-cbcc-4ea1-b4e1-25a9555de0f2" TYPE="crypto_LUKS" PARTUUID="b1d3b8a3-125e-9f4c-b624-e0db7e84c4be"
/dev/sda1: LABEL_FATBOOT="NO_LABEL" LABEL="NO_LABEL" UUID="8901-DC4B" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="a3a8eadc-e266-aa48-be08-d393c88cc8d4"

I have also tried running systemd-cryptsetup-generator with an empty folder as first parameter to see the files it generates. It doesn’t generate a file for drive b and thus seems to operate correctly. Nonetheless, I always end up with a systemd unit without a unit file for drive b after I reboot.

systemctl status systemd-cryptsetup@luks\\x2d6ed8cf7b\\x2d1fb2\\x2d4dad\\x2d9648\\x2d14adb275e8f7.service 
× systemd-cryptsetup@luks\x2d6ed8cf7b\x2d1fb2\x2d4dad\x2d9648\x2d14adb275e8f7.service
     Loaded: not-found (Reason: Unit systemd-cryptsetup@luks\x2d6ed8cf7b\x2d1fb2\x2d4dad\x2d9648\x2d14adb275e8f7.service not found.)
     Active: failed (Result: exit-code) since Sat 2024-09-14 11:44:36 CEST; 24min ago
 Invocation: 52415f836dd04834951ded7d418f129f
   Main PID: 529 (code=exited, status=1/FAILURE)
   Mem peak: 1G
        CPU: 19.952s

Sep 14 11:44:30 val systemd-cryptsetup[529]: Failed to activate with specified passphrase. (Passphrase incorrect?)
Sep 14 11:44:32 val systemd-cryptsetup[529]: Set cipher aes, mode xts-plain64, key size 256 bits for device /dev/sdc1.
Sep 14 11:44:34 val systemd-cryptsetup[529]: Failed to activate with specified passphrase. (Passphrase incorrect?)
Sep 14 11:44:34 val systemd-cryptsetup[529]: Set cipher aes, mode xts-plain64, key size 256 bits for device /dev/sdc1.
Sep 14 11:44:36 val systemd-cryptsetup[529]: Failed to activate with specified passphrase. (Passphrase incorrect?)
Sep 14 11:44:36 val systemd-cryptsetup[529]: Too many attempts to activate; giving up.
Sep 14 11:44:36 val systemd[1]: systemd-cryptsetup@luks\x2d6ed8cf7b\x2d1fb2\x2d4dad\x2d9648\x2d14adb275e8f7.service: Main process exited, code=exited, status=1/>
Sep 14 11:44:36 val systemd[1]: systemd-cryptsetup@luks\x2d6ed8cf7b\x2d1fb2\x2d4dad\x2d9648\x2d14adb275e8f7.service: Failed with result 'exit-code'.
Sep 14 11:44:36 val systemd[1]: Failed to start Cryptography Setup for luks-6ed8cf7b-1fb2-4dad-9648-14adb275e8f7.
Sep 14 11:44:36 val systemd[1]: systemd-cryptsetup@luks\x2d6ed8cf7b\x2d1fb2\x2d4dad\x2d9648\x2d14adb275e8f7.service: Consumed 19.952s CPU time, 1G memory peak.

2000 · September 14, 2024, 7:42pm

Still no idea why you’re being asked for a passphrase for /dev/sdc1 (drive b).

But there’s something else, why does your /etc/crypttab contain crypto_keyfile.bin as password? Shouldn’t it be a simple none to unlock with a passphrase on boot?

alteredstate · September 18, 2024, 12:47pm

Indeed, the crypto_keyfile.bin is not necessary as far as I can tell. This is a remnant from an earlier version of EndeavourOS I believe. This system was set up initially some time in 2021 and while I did try and stay up to date with most changes (pulseaudio → pipewire, mkinitcpio → dracut to name a few) I noticed a lot of differences to a new device set up with a 2024 image recently - the crypt setup being one.

Thanks a lot for your time and energy, @2000 !

If anybody else has an idea why I’m getting the password prompt, feel free to chime in! Eventually I’ll not have multiple drives in my Linux machine anymore so the problem will go away one way or another but until then I’m happy about any input.