How to change encrypted partition password attempts at boot?

I’m on Leap 15.3 and have an encrypted home partition. Currently at boot I am allowed only three attemtps at inputting the password correctly before the boot process stops requesting the password and just stalls because it can decrypt the home partition. The closest similar question I could find was https://unix.stackexchange.com/questions/681104/how-can-you-change-number-of-allowed-password-attempts-for-luks-encrypted-bootup. However the only reply said to look at how initramfs was setup and figure out the config for cryptsetup there. I couldn’t join the dots and figure out where to look. Any pointers would be helpful.

Here’s the contents of the crypttab if that helps:

sudo cat /etc/crypttab                                                                                               1 ✘  10:35:04   
cr_home  UUID=36725e15-c462-4a5a-9807-68b5e4d09cfb

Notes:

  1. I don’t have an ecrypted boot partition, just an ecrypted home partition.
  2. I know I can use a key file to auto decrypt the encrypted home partition at boot, but I don’t want that. I just want more attempts (preferably no limit) on prompting for the decryption password at boot.

I have an encrypted home partition on Thumbleweed but when that times out, the system continues and does fall in another prompt where there is an option to still enter the password to continue and that works.

See here, I would try adding “x-systemd.device-timeout=0” to the entry of the drive in /etc/fstab

Thanks. I tried it out but it didn’t help with the scenario where I enter the wrong password thrice. The boot process mentions the following:


[FAILED] Failed to start Cryptography Setup for cr_home.
See `systemctl status systemd-cryptsetup@cr_home.service` for details.
[DEPEND] Dependency failed for Local Encrypted Volumes.
[OK] Reached target Block Device Preparation for /dev/mapper/cr_home.
[OK] Stopped target Block Device Preparation for /dev/mapper/cr_home.

It then also has a log line that says “A start job is running for … no timeout)”. So the parameter “x-systemd.device-timeout=0” has kept the boot process waiting for the device, but it didn’t solve for the max number of attempts allowed on the decryption password.

Poking around some more lead me to https://github.com/dracutdevs/dracut/blob/master/modules.d/90crypt/crypt-lib.sh. I modified this locally on my install at /usr/lib/dracut/modules.d/90crypt/crypt-lib.sh. [FONT=arial]I set the variables ply_tries, tty_tries and tries to 5. Ran dracut -f. Rebooted. No change. I had little hope, those are just defaults I changed. The caller of the function in this case is explictly passing in the number or tries. I wish I knew what calls this so I could modify it’s config.

The other thing I tried with no success is to setup [FONT=courier new]/etc/crypttab-initramfs with the following contents:
[/FONT][/FONT]

home    UUID=36725e15-c462-4a5a-9807-68b5e4d09cfb       none    tries=0

[FONT=arial]

That didn’t do anything for me either.[/FONT]

Have you tried putting that “tries=0” in “/etc/inittab”, and then running “mkinitrd” to recreate the “initrd” file?

I have not run into this problem. But maybe I don’t mistype often enough.

That file doesn’t exist by default for me. Can I just add it? What should the contents be?

/etc/crypttab

I assume this was a"slip of the mind" and that @nrickert wanted to say /etc/crypttab

From man crypttab

tries=
Specifies the maximum number of times the user is queried for a password. The default is 3. If set to 0, the user is queried for a password indefinitely.

This file is used by built-in dracut module, on openSUSE dracut is using systemd and systemd-cryptsetup.

/etc/crypttab-initramfs

What gave you the idea to use this file?

Oops, you are right. That was a bad typo.

I think it was reading through dm-crypt - ArchWiki that made me think I needed crypttab-initramfs.

This worked for me. Thank you all :slight_smile: