Closed T35R6braPwgDJKq closed 2 years ago
does anybody know how to tackle this? Booting takes 5 minutes that way
The cryptsetup@
systemd unit should be started in the format cryptsetup@<mapper name>
- or is luks-xxxxxxx
what you use as a LUKS volume mapper name?
Did you try rebuilding the initramfs (using the dracut
tool)? The crypt module should populate the cmdline with the correct UUIDs for mounted LUKS volumes.
I do not understand why you would want to switch away from UEFI though. If you built the initramfs in UEFI mode, chances are something in the device configuration changes upon switching to Legacy mode.
my luks mapper name is root
yes i did (dracut -f /boot/initramfs-linux.img
) - the UUIDs were and are correct (in dracut.conf
as well as in dracut output) - the UUID being searched for is correct as well. Its like dracut wouldnt know that the root uuid is only available after decryption hence ignoring rd.luks.uuid
altogether
--no-hostonly-cmdline
nor --no-hostonly
nor --no-hostonly-cmdline --no-hostonly
work either
the question is not related to the problem but there are still systems without EFI... I built the image obviously in an non-UEFI environment. Just for testing purposes I switched the VM to EFI and rebuilt the image.
it seems usr/lib/systemd/system-generators/systemd-cryptsetup-generator
does not work correctly with /etc/cmdline.d/01-default.conf
Workaround:
append rd.luks.uuid=c1a0bfdc-f46b-4bfd-b622-d3e2afcb42b2
to bootloader
--no-hostonly-cmdline
nor--no-hostonly
nor--no-hostonly-cmdline --no-hostonly
work either
hostonly
is a requirement for the module to build /etc/crypttab
.
rd.luks.uuid=
should be appended automatically.
well the crypttab should be empty - only the root device is mentioned but as kernel parameter, but it doesnt really matter since I also tried an image without those arguments.
rd.luks.uuid
is appended to /etc/cmdline.d/01-default.conf
- but from there it is ignored.
It should NOT be added to the bootloader automatically. That is just my ugly workaround.
Describe the bug On a bios system (VM): i get
dracut-initqueue[479]: failed to start systemd-cryptsetup@luks-a4465013-c35b-4378-ae5f-c2bb7712b89e.service: Unit systemd-cryptsetup@luks-a4465013-c35b-4378-ae5f-c2bb7712b89e.service not found.
This unit is supposed to be generated (from /etc/crypttab
) by systemd-cryptsetup-generator
. The problem is that the generator only generates units if it sees luks
or--in our case--rd.luks
on the kernel command line and systemd only reads /proc/cmdline
. IOW, there's nothing dracut can do here; your best bet is to open an issue at https://github.com/systemd/systemd, asking for systemd to look at /etc/cmdline
and /etc/cmdline.d/*.conf
too.
thank you very much. that makes sense
The problem is that the generator only generates units if it sees
luks
or--in our case--rd.luks
on the kernel command line and systemd only reads/proc/cmdline
. IOW, there's nothing dracut can do here
In the discussion; /etc/kernel/cmdline
is read as well; so the correct thing on dracut when it's using systemd for init would be to put commandline arguments there.
EDIT: I tried manually putting a file with the correct cmdline arguments in the initrd at that location and yet the error persists. So it's systemd that is at fault. Also worth mentioning here that it's a wontfix
on systemd end.
Describe the bug On a bios system (VM): i get
In the maintenance shell I can just call
and exit the shell - the boot continues
Distribution used Archlinux
Dracut version
Init system Which init system is being used?
To Reproduce The dracut confs commandline
Expected behavior When I switch to UEFI (
uefi=yes
anduefi_stub=...
) it works - the password is asked, no timeout happensAdditional context Add any other context you like about the problem here.