[Bug 1724035] [NEW] Fails to decrypt /boot with grub-efi default configuration

[Roman Odaisky]

Public bug reported:

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-reencrypt --new.
Then I chrooted, added an entry to crypttab, added
GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub and ran update-initramfs
-u; update-grub; grub-install. I ended up with:

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.

** Affects: grub2 (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1724035

Title:
  Fails to decrypt /boot with grub-efi default configuration

Status in grub2 package in Ubuntu:
  New

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-reencrypt --new.
  Then I chrooted, added an entry to crypttab, added
  GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub and ran update-initramfs
  -u; update-grub; grub-install. I ended up with:

  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1724035/+subscriptions