Fails to decrypt /boot with grub-efi default configuration
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
grub2 (Ubuntu) |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
I took a fully functional EFI-based Ubuntu installation running artful RC and decided to start using full disk encryption. I booted from removable media, shrank my LVM PV and did cryptsetup-
sda1 -- ESP
sda2 -- LUKS -- LVM (/ is here, including /boot)
So far so good, this should have done the trick, but the system ended up unbootable. update-grub does add the necessary commands to grub.cfg... and then places that grub.cfg inside the encrypted container, putting only a short grub.cfg into the ESP that redirects to the former.
grub-install should signal an error if components that are essential for decryption of the container are inside the container. The workaround can be as simple as mv /boot/grub /boot/efi/grub && ln -s /boot/efi/grub /boot/grub; but silently proceeding is unacceptable.
Additionally, I wonder if it should become recommended practice for GRUB to reside entirely in the ESP, as opposed to the current approach where it’s partly there and partly in /boot.
We don't currently support this form of full-disk encryption without the manual interventions you mentioned, and the installer currently sets up encryption is a way that things will work.
Setting Triaged/Wishlist as this constitutes an obviously valid enhancement request.