0

I have Windows 11 running on my Acer laptop (with UEFI). I have shrunk the partition to free up 50GB of space, prepared the USB device with Linux distribution and booted the installer. Now, on the partitioning step, I did the following:

  1. Created encrypted volume on the whole 50GB free space.
  2. Set the LVM in the encrypted volume - 1 physical volume, 1 volume group, 1 logical volume with 4 partitions (swap, root, home and tmp)
  3. Written changes to the disk, installed system. Reboot.

Laptop now boots directly to the Windows. When I interrupt the booting sequence and force it to boot linux or * (depending on when the booting sequence appears), it results in an error message with fallback to the grub recovery shell.

Below are screens from the booting error and partitioning scheme (obtained by landing in grub console from OS installer).

I've done some reading on that matter and first thing that comes to my mind that I'm lacking some non-encrypted boot partition, or I messed up the encryption via GUI installer (maybe I should change the parameters of encryption, so BIOS can recognize/decrypt partition).

What could be best in this scenario? I can recreate the partitioning step once again, no problem, as long as I still have access to the Windows.

enter image description here

enter image description here

Improve this question
7
  • You're probably using unencrypted /boot. Maybe it also has to be outside of LVM - I'm not sure.
    – gronostaj
    Commented Sep 16, 2022 at 14:03
  • @gronostaj Well, I didn't create or modify explicitly any boot partition, so I think it is using the original one created by Windows. Which is non-encrypted.
    – Kamil Gierach-Pacanek
    Commented Sep 16, 2022 at 14:09
  • 1
    You probably mean the EFI System Partition. That's different than /boot (although you can merge them, but most distros will use separate ones). ESP stores bootloaders, while /boot is for kernels and initramfs. Exception: systemd_boot will happily boot kernels from ESP, Pop!_OS uses that
    – gronostaj
    Commented Sep 16, 2022 at 14:13
  • So maybe that's what I'm missing - I should've created a specific /boot mount point? Won't that be laid in / root if I won't create it manually on a separate partition?
    – Kamil Gierach-Pacanek
    Commented Sep 16, 2022 at 14:20
  • Exactly. You end up with the kernel on the encrypted volume which is probably locked at this stage. Actually I think you can configure GRUB to unlock the disk, but you'll have to enter the LUKS password twice (once in GRUB, then again on Linux boot) and security benefits are small. It gives you slightly better protection against evil maid attacks because the kernel+initramfs can't be tampered with, but GRUB is still vulnerable, so there's that.
    – gronostaj
    Commented Sep 16, 2022 at 14:31

1 Answer 1

Reset to default
0

The easiest way to get this setup to work will be to move /boot to a separate unencrypted partition outside of LVM.

With your current setup GRUB must first unlock the encrypted partition (asking you for a password) and then access the / LVM volume because your kernel and initramfs are in there. This is possible, but trickier to set up and slightly inconvenient (Linux will ask you for the password again on boot). In my opinion security benefits are not worth it, because while your kernel and initramfs are now protected by encryption, GRUB and its config still aren't (and that would require building a self-contained GRUB package and signing it with custom keys).

A separate partition without LVM and LUKS makes this way easier: GRUB loads the kernel and initramfs from there without the need for a special config, then Linux deals with the complexity.

Improve this answer
1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .