Bug#924151: grub2-common: wrong grub.cfg for efi boot and fully encrypted disk

[Colin Watson]

Control: tag -1 help

On Sun, Mar 10, 2019 at 05:30:02PM +0100, Joerg Jaspert wrote:
> On 15337 March 1977, Colin Watson wrote:
> > (Not by guided partitioning though, as I believe that always gives you a
> > separate unencrypted /boot right now, and you have to arrange for
> > GRUB_ENABLE_CRYPTODISK=y to be set.)
> 
> Granted, yes, I won't complain if you downgrade it a tad due to that.

For now I'm less interested in the severity than in what's going on and
how to reproduce it.

> > I tried reproducing this today and couldn't.  Now, I was doing it by
> > setting up a matching stretch installation (somewhat by accident) and
> > then upgrading, but still ...
> 
> I used the "Debian GNU/Linux buster-DI-alpha5 "Buster" - Official
> Snapshot amd64 DVD Binary-1 20190126-00:15" image for it.
> And since the install apt update.

Hmm.  I tried doing that in a virt-manager VM as follows:

 * started with a buster alpha-5 netinst ISO rather than the full DVD
   image, since my bandwidth is very limited
 * configured VM to use UEFI
 * guided partitioning; selected full-disk encryption; deleted /boot
   partition; accepted all other defaults
 * waited for grub-installer to fail, then appended
   GRUB_ENABLE_CRYPTODISK=y to /target/etc/default/grub and tried again
 * ran into #918590 and mounted /target/run to work around it

With this setup, everything worked fine; it seems to end up with a very
similar partitioning setup to what you've described, only four lines in
/boot/efi/EFI/debian/grub.cfg the same as you described, and yet
everything works fine.

I'd be very grateful for any help in working out how to construct a VM
that replicates this bug.

Thanks,

-- 
Colin Watson                                       [cjwatson at debian.org]