[SOLVED] boot freeze (EFI, fulldisk luks decryption)

[freifunk_connewitz]

Hi,

On a new ultrabook I try to install Gentoo according to Sakaki's great guide: dual boot with Win10, fully encrypted etc. (https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide)

After the first installation round, when it comes to the first boot of the newly installed Gentoo, the boot process crashes:
- first, the Fujitsu logo screen sits there unusually long before booting starts
- first error: "WARNING:Failed to connect to lvmetad. Falling back to device scanning"
- then the boot process correctly identifies the encrypted root ("working on /dev/disk/by-partuuid/...") and tries to unlock it with the key file
- but it fails to locate or open the usb stick where the key file resides:
- first it asks for "Insert device... You have 10 seconds"
- then it tries to mount the HDD (NVMe) partitions, and dumps the error message of the missing key to decrypt the luks partition: "Could not find the root_[PARTUUIDof the Luks device]... key device [then follows the -correct!- PARTUUID of the usb stick partitition where the key is at]"
- then it tells me to issue 'shell' for a shell, 'Enter' for repeat, or 'q' for quit, but nothing happens if I do so, not even ctrl-alt-del works, I have to switch the laptop off with the power button.

It is almost the same problem as here: https://forums.gentoo.org/viewtopic-t-1073720-start-0.html.

The kernel command line parameters are those provided by the buildkernel-script from Sakakis overlay.

The stick is ok, I checked it with another computer. There I can also see the EFI kernel and config in their correct location, as the luks-key.gpg file. The PARTUUID of the stick when checked at the other computer is exactly the same as asked for by the boot process.

Secure Boot is off. For kernel compilation I used Sakakis standard options. buildkernel is version 1.0.35

EDIT: Even when I discard the whole USB drive / keyfile mechanism and install the kernel via the buildkernel utility onto the EFI system partition on the harddrive: the error persists. Booting freezes as soon as it comes to ask for the password for the LUKS encrypted root.

Can it be a hardware problem / laptop too new? It's a Fujitsu U 939. At least, the Gentoo Live USB medium completely failed to boot the machine (blank screen). I had to use RescueCD 6.0.3 to be able to start the Gentoo installation. Unfortunately, I have no idea which component failed the Gentoo Live System.

Your help is very much appreciated.

[389292]

Such complex installations are very difficult to debug and assist you in solving your problem. The only thing I can suggest you is to start with much simpler setup, no dual boot, no lvm, no gpg, only LUKS encryption, a keyfile and a custom made initramfs. This way you can decipher the complexity and understand what does what in such installation (because tools like genkernel hide a lot from you). After you succeed in base encrypted install you can add lvm and more complexity on top of that, but still stay away from gpg, it's not really necessary, you can make your keyfile from /dev/random, put it on an encrypted /boot partition and use this keyfile to decrypt the rest of the drives, it will be less susceptible to errors due to gpg versions etc.

[freifunk_connewitz]

Thank you, etnull, for your answer. I've already cut back complexity in dropping gpg and moving the kernel to the EFI partition on HDD instead of the USB stick. I will try to break away from Sakaki's guide and tools here and try to bake a normal kernel and initramfs using genkernel - and probably using Grub. EFI alone (I had bad experiences with it on another machine already) seems to be unreliable to me when it comes to dual boot of Win and Gentoo. But unfortunately it is not an option to delete the Windows partition, I'm gonna need it about twice a year.

I'm still wondering why the Gentoo install medium failed to boot my laptop (while Arch/RescueCD and Ubuntu succeeded). Does nobody else have such problems? The hardware is not that exotic - almost everything Intel: CPU, GPU, net, wifi, PCI, NVMe...

[Hu]

[freifunk_connewitz]

[Hu]

Since the system does not react to entering the passphrase, I should ask: does the system know it has a keyboard? If your keyboard is not supported by your kernel, nothing you type will have any effect.

When using an external USB key, anything done by the bootloader is irrelevant to the kernel. The kernel may not be able to access the USB key, even if the bootloader could.

[NeddySeagoon]

freifunk_connewitz,

[freifunk_connewitz]

[NeddySeagoon]

freifunk_connewitz,

[freifunk_connewitz]

Neddy Seagoon,

[NeddySeagoon]

freifunk_connewitz,

20 years ago, the "Decompressing Linux ..." was on the screen for several seconds.
As hardware has got faster, so that message has become briefer.

Don't assume that because you don't see it, its not there.
Its also possible that the kernel cannot drive the console until that message has come and gone.

Please post the output of

[freifunk_connewitz]

Thank you, Neddy, for your suggestions. It indeed was a kernel configuration problem. I removed .config and went through makeconfig again, according to my hardware, rebuilt initram, run grub-mkconfig, rebooted and had a successfully booting kernel.

The next snag I hit was that Grub cannot handle my LUKS root partition because it's LUKS2-formatted. So I think I have to reformat that partition to LUKS1 and copy the backup onto it.

[389292]

[freifunk_connewitz]

Summarizing for those who hit similar problems:

• If you have to boot a new machine with a different Live system than Gentoo, e.g. RescueCD, or Ubuntu, (because Gentoo's minimal install won't boot) than take care when it comes to configuring your new kernel. Do not simply incorporate the kernel config of the running live-system kernel into your config. Rather start from scratch (without existing .config) or use the defaults from genkernel or the like.
  
• If you want to install your new system with a LUKS full disk encryption double check if your booting kernel and tools will be able to decrypt the LUKS device/partition. My experience says to avoid LUKS2 when formatting your new LUKS container/device/partition. Use "--type luks1" while performing LuksFormat. In my case neither Grub (which is known and officially so) nor the EFI-kernel-including-initramfs method proposed by Sakaki's guide succeeded in opening my LUKS2-formatted partition. As soon I reformatted it as LUKS1, decryption worked.