Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dracut fails to auto-detect encrypted partition #2686

Open
ManuInDenWolken opened this issue Feb 19, 2025 · 0 comments
Open

Dracut fails to auto-detect encrypted partition #2686

ManuInDenWolken opened this issue Feb 19, 2025 · 0 comments
Labels
bug Our bugs

Comments

@ManuInDenWolken
Copy link

Describe the bug
I have a simple full disk encrypted setup, meaning an unencrypted EFI system partition (/dev/vda1), an encrypted swap partition (/dev/vda2) and an also encrypted root partition (/dev/vda3). When I expected dracut to build the initramfs with rd.luks.uuid entries for all my encrypted partitions, it only did add a parameter for my root partition.

Distribution used
Gentoo Linux

Dracut version
dracut 106

Init system
OpenRC

To Reproduce
I am not so sure. It happened right out of the box, despite me not noticing it at first, because the system was starting just fine. There was just a single line of "Failed to enable swap" (or something like that). I actually got it working by decrypting (cryptsetup luksOpen ...), enabling (swapon) the swap partition, then rebuilding the initramfs. But the next time I rebuilt the initramfs after a restart, same problem again.

Expected behavior
Dracut is supposed to find all partitions of type crypto_LUKS and add them to the cmdline for decryption.

Additional context
Problem doesn't occur on my Void Linux system, both Swap and Root partition are detected perfectly.
When I debugged the state dracut within the crypt module, I found that only three partitions were listes by the host_fs_types array used by the cmdline hook of the crypt module - /dev/vda1 (EFI system partition), /dev/vda3 (root partition) and /dev/dm-0. Consequently, I looked for the only other place where this array is referenced and I found the line 1597-1630 in which host_fs_type is initialized. I debugged some state there and the fstab_lines, on which basis the host_fs_type array is filled, seems to be empty. And since I have no idea where this fstab_lines array comes from and how it's initialized, I want to pass this on. Documentation of all these variables exported the main script is pretty terrible, origin hard to find (tough, my knowledge of bash scripting is limited, if not terrible).

Any help is appreciated. Thanks in advance!

@ManuInDenWolken ManuInDenWolken added the bug Our bugs label Feb 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Our bugs
Projects
None yet
Development

No branches or pull requests

1 participant