Problem description
The boot process halts on Fedora 40 after the user enters the disk decryption password.
Note: Some details are redacted ([...]
, [partition device name]
, etc).
Boot logs
The following is a transcription of logs displayed on-screen during the boot sequence:
Please enter passphrase for disk [...] (luks-[...]):
device-mapper: table: 253:0 crypt: unknown target type
device-mapper: ioctl: error adding target to table
[FAILED] Failed to start systemd-cryptsetup@luks\x[...]
[DEPEND] Dependency failed for cryptsetup.target - Local Encrypted Volumes
[ OK ] Reached target sysinit.target - System Initialization.
[ OK ] Reached target basic.target - Basic System.
Affected kernels
The following kernels are affected and will not boot:
6.8.10-300.fc40.x86_64
(fc40
)6.8.11-300.fc40.x86_64
(latest
)
The following kernel is not affected:
6.8.10-200.fc39.x86_64
(fc39
)
Encrypted partition details
After a boot from the unaffected kernel, the block device (luks-[...]
/253:0
) mentioned in the above logs was found in the following files and command outputs:
The first encrypted partition matches the block device by UUID. From /etc/crypttab
(line #1):
luks-[...] UUID=[...] none discard
A match between the UUID and device numbers. From lsblk
:
├─[partition device name] 259:7 0 [size] 0 part
│ └─luks-[...]
│ 253:0 0 [size] 0 crypt /home
Encryption parameters of the block device. From cryptsetup status /dev/mapper/luks-[...]
:
/dev/mapper/luks-[...] is active and is in use.
type: LUKS2
cipher: aes-xts-plain64
keysize: 512 bits
key location: keyring
device: /dev/[partition device name]
sector size: 512
mode: read/write
flags: discards
Investigating ramdisk contents
The following command output describes the initial ramdisks for the (fc39
) and (fc40
) kernels. The output was produced using lsinitrd
.
This output establishes the presence of modules enabling dm-crypt
device-mapper encryption in either ramdisk. Only relevant parts of the command output are included.
The (fc39
) kernel
Image: /boot/initramfs-6.8.10-200.fc39.x86_64.img: 56M
Version: dracut-059-16.fc39
Arguments: -f
dracut modules:
crypt
dm
-rw-r--r-- 1 root root 28444 Nov 16 2023 usr/lib/modules/6.8.10-200.fc39.x86_64/kernel/drivers/md/dm-crypt.ko.xz
The (fc40
) kernel
Image: /boot/initramfs-6.8.10-300.fc40.x86_64.img: 48M
Version: dracut-101-1.fc40
Arguments: -f --kernel-image '/lib/modules/6.8.10-300.fc40.x86_64/vmlinuz' --kver '6.8.10-300.fc40.x86_64'
dracut modules:
crypt
dm
-rw-r--r-- 1 root root 28316 May 16 [time] usr/lib/modules/6.8.10-300.fc40.x86_64/kernel/drivers/md/dm-crypt.ko.xz
Note: The size discrepancy between the (fc39
) and (fc40
) ramdisks seems to be a result of certain modules being excluded from the (fc40
) kernel ramdisk, such as bash
, dbus
, and network-related kernel modules.
Detailed ramdisk comparison
The following is a comparison of the file names present in the (fc39
) and (fc40
) kernel ramdisks. The comparison only targets file names containing crypt
. To prevent false positives, file paths were sanitized as not to contain the kernel version.
Experiments
The following experiments were run to further diagnose the issue:
Booting to initrd shell
To query loaded kernel modules, a boot into the initrd shell was attempted using the rd.shell
flag on the (latest
) kernel in GRUB. The boot sequence was not affected by this flag.
Booting to emergency shell
To query loaded kernel modules, a boot into systemd’s emergency shell was attempted twice, using the systemd.unit=emergency.target
and systemd.unit=rescue.target
kernel flags on the (latest
) kernel in GRUB. The boot sequence was not affected by these flags.
Mitigations
The following mitigations were put in place:
Kernel rotation
To prevent the unaffected kernels from being rotated out, the following edit was made to /etc/dnf/dnf.conf
:
installonly_limit=0