Arch Linux

expoodo

Member

From: Toronto, Canada

Registered: 2024-01-02

Posts: 15

No second attempt when entering wrong password for LUKS volume

When I enter a wrong password when the boot stage asks for a password, it errors and then hangs indefinitely, requiring me to press Ctrl-alt-delete. I am using systemd-boot with a UKI generated by mkinitcpio, with a LUKS encrypted partition on a Framework 13 (Ryzen 7640u).

This is what the boot messages show after I enter the wrong password

mkinitcpio.conf:

# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES=(usbhid xhci_hcd)
MODULES=()

# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image.  This is run last, so it may be used to
# override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES=()

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way.  This is useful for config files.
FILES=()

# HOOKS
# This is the most important setting in this file.  The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added.  Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
##   This setup specifies all modules in the MODULES setting above.
##   No RAID, lvm2, or encrypted root is needed.
#    HOOKS=(base)
#
##   This setup will autodetect all modules for your system and should
##   work as a sane default
#    HOOKS=(base udev autodetect modconf block filesystems fsck)
#
##   This setup will generate a 'full' image which supports most systems.
##   No autodetection is done.
#    HOOKS=(base udev modconf block filesystems fsck)
#
##   This setup assembles a mdadm array with an encrypted root file system.
##   Note: See 'mkinitcpio -H mdadm_udev' for more information on RAID devices.
#    HOOKS=(base udev modconf keyboard keymap consolefont block mdadm_udev encrypt filesystems fsck)
#
##   This setup loads an lvm2 volume group.
#    HOOKS=(base udev modconf block lvm2 filesystems fsck)
#
##   This will create a systemd based initramfs which loads an encrypted root filesystem.
#    HOOKS=(base systemd autodetect modconf kms keyboard sd-vconsole sd-encrypt block filesystems fsck)
#
##   NOTE: If you have /usr on a separate partition, you MUST include the
#    usr and fsck hooks.
HOOKS=(systemd autodetect microcode modconf kms keyboard sd-vconsole block plymouth sd-encrypt filesystems)

# COMPRESSION
# Use this to compress the initramfs image. By default, zstd compression
# is used for Linux ≥ 5.9 and gzip compression is used for Linux < 5.9.
# Use 'cat' to create an uncompressed image.
#COMPRESSION="zstd"
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
#COMPRESSION="lz4"

# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=()

# MODULES_DECOMPRESS
# Decompress loadable kernel modules and their firmware during initramfs
# creation. Switch (yes/no).
# Enable to allow further decreasing image size when using high compression
# (e.g. xz -9e or zstd --long --ultra -22) at the expense of increased RAM usage
# at early boot.
# Note that any compressed files will be placed in the uncompressed early CPIO
# to avoid double compression.
#MODULES_DECOMPRESS="no"

Kernel command-line:

root=UUID=c32c456f-e19b-4525-a5b2-101f1d42e9bd rootflags=subvol=root rw quiet splash
kernel.nmi_watchdog=0 nowatchdog
pcie_aspm.policy=powersupersave usbcore.autosuspend=1
rd.luks.uuid=83331e41-e82f-43d8-8053-38e8e3349a5f
rd.luks.options=83331e41-e82f-43d8-8053-38e8e3349a5f=tpm2-device=auto,password-echo=yes
lockdown=integrity

Last edited by expoodo (2025-01-14 00:01:10)

mackin_cheese

Member

Registered: 2025-01-07

Posts: 68

Re: No second attempt when entering wrong password for LUKS volume

What research have done so far regarding this issue?

expoodo

Member

From: Toronto, Canada

Registered: 2024-01-02

Posts: 15

Re: No second attempt when entering wrong password for LUKS volume

What research have done so far regarding this issue?

I've tried googling if there were any posts similar to my problem, but the only post I could find was this, but it was based around grub.

Last edited by expoodo (2025-01-14 01:05:17)

dimich

Member

From: Kharkiv, Ukraine

Registered: 2009-11-03

Posts: 300

Re: No second attempt when entering wrong password for LUKS volume

I am using systemd-boot

Are you sure sd-encrypt ever implements retries on wrong password?

nl6720

The Evil Wiki Admin

Registered: 2016-07-02

Posts: 665

Re: No second attempt when entering wrong password for LUKS volume

sd-encrypt tries three times by default. See the description of tries= in crypttab(5).

Testing it in a VM I have, the first wrong password strangely seems to use up two tries.

Edit:
You're using plymouth, so this could be an issue specific to plymouth.

Last edited by nl6720 (2025-01-14 12:33:37)

dimich

Member

From: Kharkiv, Ukraine

Registered: 2009-11-03

Posts: 300

Re: No second attempt when entering wrong password for LUKS volume

sd-encrypt tries three times by default. See the description of tries= in crypttab(5).

"tries=" from /etc/crypttab takes effect when systemd-cryptsetup asks for password by itself, not with plymouth. Also it seems like systemd-cryptsetup counts any method to get a key as a try.

It would be helpfull to enable debug log level and see boot logs.

expoodo

Member

From: Toronto, Canada

Registered: 2024-01-02

Posts: 15

Re: No second attempt when entering wrong password for LUKS volume

You're using plymouth, so this could be an issue specific to plymouth.

I removed the plymouth hook, but that made no difference.

It would be helpful to enable debug log level and see boot logs.

I tried using `debug` and `systemd.log-level=debug`  cmdline options, but they outputted nothing when I entered the wrong password. I can't see the previous boot logs because the disk is still encrypted in the first place. Do you know of any other way of making systemd boot logs more verbose?

EDIT: I wonder if this is actually intended behaviour for the sd-encrypt hook? My fedora setup automatically asks for the password again if previous was wrong, so I just expected it here.

Last edited by expoodo (2025-01-15 00:50:11)

dimich

Member

From: Kharkiv, Ukraine

Registered: 2009-11-03

Posts: 300

Re: No second attempt when entering wrong password for LUKS volume

Do you know of any other way of making systemd boot logs more verbose?

Sorry, I don't use systemd-boot so can't give a specific advice.
I'd try to add

Environment=SYSTEMD_LOG_LEVEL=debug

to [Service] section of corresponding service units, and re-generate initramfs. However, I'm not sure journal from initramfs is preserved after transition to normal rootfs. Can you see messages from other services run in initramfs?

expoodo

Member

From: Toronto, Canada

Registered: 2024-01-02

Posts: 15

Re: No second attempt when entering wrong password for LUKS volume

Environment=SYSTEMD_LOG_LEVEL=debug
to [Service] section of corresponding service units, and re-generate initramfs. However, I'm not sure journal from initramfs is preserved after transition to normal rootfs. Can you see messages from other services run in initramfs?

I could not find the supposed systemd-cryptset service in my system, so I guess it's an autogenerated service? If you mean if I can see initramfs boot messages in the journal on a success boot, I can see them, but I couldn't find anything useful

dimich

Member

From: Kharkiv, Ukraine

Registered: 2009-11-03

Posts: 300

Re: No second attempt when entering wrong password for LUKS volume

I could not find the supposed systemd-cryptset service in my system, so I guess it's an autogenerated service?

Yes, it is generated by systemd-cryptsetup-generator at runtime. And it doesn't seem to be possible to break systemd-based initramfs with break kernel parameter. If you find a way to get into shell before cryptsetup, you can edit service unit (it should be somewhere in /run/systemd/), edit it, run `systemctl daemon-reload` and continue boot process.