grub-install removes other EFI boot entries

[Chad Miller]

Suppose you have some kind of RAID array. You expect disks to burst into flame, and the machine continue to work.

Without some special effort, grub will insist that exactly one EFI entry is active for Ubuntu, which is not what we should want. If the disk fails that has the only boot entry on it, then you don't boot again!

EFI has a boor order built-in. There's no reason to insist on having exactly one.

Here's a healthy EFI configuration with two disks, each of which can be used for booting to Ubuntu. Then, we install grub to a third disk. "grub-install" removes the other two boot entries!

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-====================-============-=======================================================
ii efibootmgr 0.12-4 amd64 Interact with the EFI Boot Manager
ii grub-common 2.02~beta2-36ubuntu2 amd64 GRand Unified Bootloader (common files)
ii grub-efi-amd64 2.02~beta2-36ubuntu2 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 version)

$ sudo efibootmgr -v
BootCurrent: 0000
Timeout: 5 seconds
BootOrder: 0001,0000
Boot0000* ubuntu HD(2,GPT,9cff8ce0-5651-4b27-9ce9-afcef877feaa,0xe8d14800,0xf4000)/File(\EFI\ubuntu\grubx64.efi)
Boot0001* ubuntu HD(2,GPT,747727cb-581b-42a3-b8d7-9bbf0b3eeff8,0x74612800,0xf4000)/File(\EFI\ubuntu\grubx64.efi)

$ ls -l /dev/disk/by-partuuid/9cff8ce0-5651-4b27-9ce9-afcef877feaa /dev/disk/by-partuuid/747727cb-581b-42a3-b8d7-9bbf0b3eeff8
lrwxrwxrwx 1 root root 10 Apr 8 10:45 /dev/disk/by-partuuid/747727cb-581b-42a3-b8d7-9bbf0b3eeff8 -> ../../sdb2
lrwxrwxrwx 1 root root 10 Apr 8 10:45 /dev/disk/by-partuuid/9cff8ce0-5651-4b27-9ce9-afcef877feaa -> ../../sda2

#### Here comes the deletion lines! "-B" is delete!
$ sudo umount /boot/efi && sudo mount /dev/sdc2 /boot/efi && sudo grub-install /dev/sdc2 -v
...
grub-install: info: copying `/boot/grub/x86_64-efi/core.efi' -> `/boot/efi/EFI/ubuntu/grubx64.efi'.
grub-install: info: Registering with EFI: distributor = `ubuntu', path = `\EFI\ubuntu\grubx64.efi', ESP at hostdisk//dev/sdc,gpt2.
grub-install: info: executing efibootmgr --version </dev/null >/dev/null.
grub-install: info: executing modprobe -q efivars.
grub-install: info: executing efibootmgr -b 0000 -B.
BootCurrent: 0000
Timeout: 5 seconds
BootOrder: 0001
Boot0001* ubuntu
grub-install: info: executing efibootmgr -b 0001 -B.
BootCurrent: 0000
Timeout: 5 seconds
No BootOrder is set; firmware will attempt recovery
grub-install: info: executing efibootmgr -c -d /dev/sdc -p 2 -w -L ubuntu -l \EFI\ubuntu\grubx64.efi.
BootCurrent: 0000
Timeout: 5 seconds
BootOrder: 0000
Boot0000* ubuntu
Installation finished. No error reported.

$ sudo efibootmgr -v
BootCurrent: 0000
Timeout: 5 seconds
BootOrder: 0000
Boot0000* ubuntu HD(2,GPT,5e30b533-242f-4aaa-8800-1bdd4e13f44e,0xe8d14800,0xf4000)/File(\EFI\ubuntu\grubx64.efi)

$ ls -l /dev/disk/by-partuuid/5e30b533-242f-4aaa-8800-1bdd4e13f44e
lrwxrwxrwx 1 root root 10 Apr 8 10:45 /dev/disk/by-partuuid/5e30b533-242f-4aaa-8800-1bdd4e13f44e -> ../../sdc2

If you're installing something that has the same name, like "ubuntu", expect all your prized redundancy to be squashed flat.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: grub-common 2.02~beta2-36ubuntu2
ProcVersionSignature: Ubuntu 4.4.0-16.32-generic 4.4.6
Uname: Linux 4.4.0-16-generic x86_64
NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
ApportVersion: 2.20.1-0ubuntu1
Architecture: amd64
CurrentDesktop: GNOME
Date: Fri Apr 8 12:56:54 2016
InstallationDate: Installed on 2014-05-07 (701 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
SourcePackage: grub2
UpgradeStatus: No upgrade log present (probably fresh install)

[Chad Miller (cmiller)]

There is a "--bootloader-id=" argument to grub-install that lets you choose a different name and only remove other entries with that new name. So, if you're careful, you can choose unique names for each and get other entries.

It's wrong and weird to remove anything by running "install" though. It might even be okay to make the most recently "grub-install"ed device the first, preferred device in the boot order, but it's not okay to remove others.

[Chad Miller (cmiller)]

My suggestion for a change is that the device id is used to construct a more complex bootloader id.

$ sudo efibootmgr
BootCurrent: 0000
Timeout: 5 seconds
BootOrder: 0002,0001,0000
Boot0000* ubuntu via WDC_WD20EFRX-68EUZN0_WD-WCC4M6HVCKR8
Boot0001* ubuntu via WDC_WD20EFRX-68EUZN0_WD-WCC4M6PP1ZJK
Boot0002* ubuntu via ST31000528AS_5VP8B3JE

[Chad Miller (cmiller)]

I just wrote this to do what I want it to do. I suspect this is beyond most users.

I don't think this should be part of the package, but I think what it does is a good idea. Include the device name and serial number in the EFI boot description. "ubuntu" was never enough anyway.

[Mathieu Trudel-Lapierre (cyphermox)]

In theory this is fine, but in practice will need more work.

For instance, in your examples grubx64.efi is being installed as the EFI binary to run -- this is wrong, since grubx64.efi is only signed by the Canonical keys, not by Microsoft keys, and so will fail to boot in a Secure Boot scenario.

I think we'll also need to rework the naming -- "ubuntu", although being perhaps too brief, has the benefit of being obvious (moreover, AIUI you can have the same label as many times as you want). It would be better to make sure update-grub and grub-install can correctly see the RAID case as it is, and DTRT; such as installing to all members of the array, adding the right modules to config (and in a Secure Boot scenario you'll also need to have the modules included in the shipped grub EFI images).

Marking Triaged / Wishlist; I'll see with other people how to prioritize this work.

[Chad Miller (cmiller)]

> AIUI you can have the same label as many times as you want

FWIW, my practical attempts say the same name can be used any number of times on some computers.

I don't like the same name, though. I don't think every boot should be a mystery about which I'm picking. It's not like the EFI menu has any smarts that lets me investigate before it goes. It might matter in ways that have nothing to do with redundancy of booting the same machine instance.

For an attempt at brevity and sanity, can we make the "ubuntu" label have appended " on $udevserialpart" IFF there is more than one disk? On install, perhaps mutate all entries starting with "ubuntu" or "ubuntu on ".

[Chad Miller (cmiller)]

cyphermox, as for your complaint about grubx64.efi, I don't understand it and I don't think I ever typed that anywhere, so it must have come from grub. My "grub-install" just passes through things like that in "$@".

[Valentijn Sessink (valentijn)]

The bug is somewhat worse than in the original report: grub-install will remove anything that has "Ubuntu" (case INsensitive!) in it's name. In a test, both "RAID Ubuntu /dev/sdc", "Ubuntu /dev/sdc" were removed by grub-install. A label "RAID fallback /dev/sdc" would survive a call to grub-install.

I'm not sure this is just a wishlist item. I can understand that grub-install removes any item named "ubuntu" (case sensitive) because it creates these. But why remove .*ubuntu.*/i ?

I agree with comment #4 that this is beyond most users.

Regarding comment #3: a sysadmin might want "ubuntu WDC_WD20EFRX-68EUZN0_WD-WCC4M6HVCKR8", but for a regular user "ubuntu" may just be fine. And having the disk ID automatically (i.e. by grub-install) added to the menu means that it will also be automatically removed - adding to complexity and to unintended side effects.

[Chad Miller (cmiller)]

I agree this shouldn't be Wishlist. I mentioned one other thing that would be nice to have when fixing an enormous error, and that was a mistake.

grub-install un-installs things. That's a big bug.