Bug#928911: grub-efi-amd64: destroys EFI partition despite being told not to
Colin Watson
cjwatson at debian.org
Sat May 25 13:08:14 BST 2019
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]
More information about the Pkg-grub-devel
mailing list