Bug#928911: grub-efi-amd64: destroys EFI partition despite being told not to

[Colin Watson]

Control: reassign -1 grub-installer

On Mon, May 13, 2019 at 12:10:07AM +0200, Adam Borowski wrote:
> Just did a d-i bare-metal test run; installing to another disk, with the
> obvious requirement of not damaging the primary system.  Thus, I explicitly
> marked all relevant partitions (EFI, sys, and swap) as "do not use".
> 
> Yet the newly installed system overwrote the ESP anyway.  It also did so in
> a way that neither the old nor new system could be booted (no entries for
> any of the existing two systems were created, and I did not succeed booting
> manually).
> 
> Disks present in the system:
> * NVME-SSD:
>   [all "do not use"] ESP (fat), sys (btrfs), swap
> * 4x NVME-Optane:
>   MD RAID0 <- new system (d-i test) was installed here
> * HDD:
>   * another old system (ext4) -- x32, BIOS-boot
>   * boot partition for the d-i test run
>   * data partition (btrfs)
> 
> It can be argued that the setup above may be a bit overcomplicated (thus
> the installer being confused might be understandable).
> But I insist that disregarding the explicit "do not use" and scribbling
> over anyway is a severe bug.

This seems as though it can only reasonably be fixed in grub-installer,
since it's what explicitly calls grub-install here.
grub-efi-amd64.postinst won't independently call grub-install in this
setup (since /boot/efi won't be mounted in the installed system, so the
-d "/boot/efi/EFI/$bootloader_id" test will fail).  Reassigning.

When installing in grub-efi* mode, I think it would probably be
reasonable for grub-installer to only call grub-install if
$ROOT/boot/efi is a mountpoint.

-- 
Colin Watson                                       [cjwatson at debian.org]