2

Key Details

My GPT layout drive has the following partition layout:

/dev/sda---|
           |sda1 - Windows Recovery Partition
           |sda2 - EFI Partition (Shared, Windows and Linux)
           |sda3 - Windows Primary Partition
           |sda4 - LUKS encrypted LVM partition
           --------| /dev/mapper/volume-group-root:   Linux root "/"
           --------| /dev/mapper/volume-group-swap_1: Linux swap 

Current Problem:

On boot, GRUB immediately prompts for the "master key". Entering the LUKS password allows the GRUB boot menu to open.

After selecting the linux OS to boot, another password prompt appears to unlock the LVM partition.

The second prompt makes sense - but why does that first one appear?

The Usual Answer

GRUB needs to decrypt the drive to read the boot files

This would make sense, but my GRUB installation should be sharing the unencrypted EFI partition with Windows. There are definitely boot files there anyway...

The steps I followed:

sudo mount /dev/mapper/volume-group-root /mnt
sudo mount /dev/sda1 /mnt/boot/efi
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
sudo chroot /mnt
grub-install /dev/sda
update-grub  

Unfortunately the problem persists. Any thoughts or troubleshooting advice appreciated.

N.B - I suspect that grub placed the files in the EFI partition, but is incorrectly configured such that it tries to look in the wrong place on boot? Both the Windows and Linux OSes boot fine though. Not sure how to investigate this.


Further Information

  • The current EFI partition is not inside the encrypted LVM. (Apologies if my diagram is unclear, advice welcome on how to make it clearer!)
  • You answer suggests I need a /boot partition and a seperate EFI partition (I think), the trouble I am having is that various internet sources suggest that only one EFI partition is needed:

This table states /boot or EFI

This answers states /boot/efi is a convention and not necessary

and finally, this source states that I can get linux to share the Windows EFI partition without any issues, which is my aim here.

Maybe this is all fstab/other config related rather than partition issues?

1 Answer 1

4

Something is off in your configuration. There should be a /boot partition that is outside the encrypted LVM partition. This partition is separate from the EFI parition. In fact, the EFI partition gets mounted at /boot/efi. The unencrypted /boot partition is what contains the initrd (initial RAM disk, a temporary root filesystem used at boot time) that houses everything needed for system decryption. The initrd, not GRUB, is what typically runs at boot time to ask you for your password and then unlocks everything in one go so you can load and run the installed system.

You will need to create a new unencrypted partition and move /boot there. Then you'll need update your /etc/fstab. If you don't have a /etc/crypttab file, you need to make one that decrypts /dev/sda4 (the UUID is typically used in this file). Then run:

sudo update-initramfs; sudo update-grub

to rebuild all of your boot files.

You can create /boot on /dev/sda or you can use another device (even a USB stick partition) if you like. Format your new /boot partition using ext[2,3,4] (use ext2 if you're putting it on a USB). The Ubuntu installer uses ext2 for the /boot partition.


Further explanation
In your further information, the table you reference is addressing Arch Linux with which I have used very little and am much less familiar. As for the second link to the mount point for the EFI partition, sticking with convention will make it easier in the long run in case you need to troubleshoot or you're setting up a system that someone else may manage. I've never tried mounting the EFI partition anywhere else, but if it works for you, go for it. If that path is hardcoded in any application that needs to access the partition, it could prove problematic.

Yes, if you already have an EFI partition, Windows and Ubuntu can happily share the same EFI partition, but the initrd files to decrypt and boot into Ubuntu are not saved on the EFI partition (/boot/efi on a standard installation). They are saved in /boot. I'm curious to know how you performed the installation as Ubuntu doesn't handle an encrypted /boot partition well. At any rate, using the graphical installer and opting for FDE results in the following partition structure:

sda
├─sda1      boot partition on    /boot
├─sda2      EFI partition on     /boot/efi
└─sda5      LUKS encrypted partition
  └─LVM PV
    ├─root  Logical Volume on    /
    └─swap  Logical Volume as swap

Perhaps Ubuntu will one day better support /boot encryption, but if you want to get by with a single password in the meantime, you're probably just going to have to create an unencrypted partition for /boot, separate and distinct from your EFI partition. There is justifiable concern about an unencrypted /boot partition which is why I mention the possibility of using a USB stick (separate device) to house your /boot partition.


Further investigation (This is most likely what you are looking for)
So I did a little digging, and it looks like others have set up systems without the /boot partition, though it was required during initial system installation. Take a look at the bottom of this article that describes a setup similar to what you say you're running. In it the author presents a fix for the second password prompt. Basically, the author walks you through creating a key file, adding it to your LUKS partition, and then tweaking the initrd file to use the key file where the system is asking you for the password the second time.

3
  • Thanks very much for taking the time to write this, I'll see what I can figure out with it later today!
    – Unencoded
    Jan 2, 2019 at 6:50
  • an edit and an upvote! ;-)
    – Fabby
    Jan 2, 2019 at 17:08
  • Okay, I've had time to go through this now, I really appreciate your help. I'm still very confused however, and have added further information to my question if you have a moment to take a look. :)
    – Unencoded
    Jan 2, 2019 at 20:09

You must log in to answer this question.

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