You are not logged in.
I'm trying to set up a new Arch system. I have running system but I have no idea any more how I set it up years ago, and I've struggling with the new system for days. Now I am at the point where at least the initramfs is loaded, but when it comes to unlocking the root partition, I never get asked for the LUKS key. The system ist stuck at "A start job is running for /dev/disk/by-uuid/....".
Other than that, the new system is fully set up and was arch-chrooted before any conf file changes. I have not forgotten to mount the EFI partition. "grub-install --efi-directory=...", "grub-mkconfig", and "mkinitcpio -P" were run in the chrooted system. It seems that the only missing thing is that the initramfs system doesn't ask for a LUKS passphrase. It doesn't matter if I put "keyboard" before or after "autodetect" in the HOOKS line of mkinitcptio.conf
AFAIK the early boot process is solely the responsibility of initramfs and GRUB, and the only two files I need to tweak are /etc/default/grub and /etc/mkinitcpio.conf
I ran a diff on both files, and here's the upshot:
Old system
GRUB_CMDLINE_LINUX="rd.luks.name=5b6df79b-1d36-4e87-b5ec-cbd8ec2ddbaf=root root=/dev/vg-arch/root"
New system
GRUB_CMDLINE_LINUX="rd.luks.name=68516eba-4043-4724-b8ce-a8aad2f46816=root root=/dev/vg-arch2/root"
/etc/mkinitpio.conf is identical on both systems.
The only difference I can think of is that the old system uses secure boot. I haven't tried to tackle that on the new one yet. This will become most likely a followup question because I have neither an idea of how I set up the old system nor how to find out how it is set up.
Last edited by musbur (2024-01-14 18:47:34)
Offline
New system usually means new uuid. Recheck you uuid, the one in the grub as well in fstab.
XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX is the UUID of the (encrypted) LUKS partition ?
UUID of the efi partition was adapted as well ?
The new system has an additional "2" - vg-arch2 - is this right ?
Post some uuid's of your system, lsblk --fs, LVM config, grub config, all with copy + paste, to have a look by us.
secure boot as problem can be ruled out, if you get to "A start job is running for /dev/disk/by-uuid/...." - it would stop earlier.
Offline
Worng UUID was the solution. I used a partuuid instead of the uuid. At first I thought that that should trigger an error message but them realized that that is no option because initramfs must wait for devices to come online and therefore cannot tell a slow device from a misspelled UUID. I later fought a much harder battle that was caused by a single double-quote sign (") after the correct UUID (leftover from a sloppy commandline-copy-and-paste): The device is detected when it comes up, the password prompt appears, the LUKS device is unlocked, and then initramfs is stuck in a "A start job is running for /dev/...." loop.
Offline