grub-install with --bootloader-id option creates unusable boot configuration with secure boot

Bug #1450783 reported by Lukas
This bug affects 8 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)

Bug Description

When manually creating an EFI boot entry using `grub-install --bootloader-id=<myid>`, where myid is a string different from "ubuntu", the resulting boot configuration is broken.

The signed grub EFI binary `grubx64.efi` seems to contain a hardcoded path to `/EFI/ubuntu`, from which grub will then read the grub.cfg configuration file specifying the UUID of the root partition. This approach only works if the bootloader id is in fact equal to "ubuntu".

Either calling grub-install with both an alternative bootloader id and UEFI secure boot options should fail and print an error explaining the situation, or the signed boot image should be fixed (i.e. the hardcoded path removed) so that it reads the grub.cfg from the same directory in which the image itself is located, which seems preferable because it allows multi-booting more than one Ubuntu installation on the same system.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

This sound like a variant of bug 1242417.

Are you only directly calling grub-install --bootloader-id=myid ? Are you setting GRUB_DISTRIBUTOR elsewhere as well?

GRUB_DISTRIBUTOR would be set in /etc/default/grub at the very least and would likely interfere with how/where things get installed as well.

That said, I also see that /EFI/ubuntu is hardcoded in efi images; I just haven't found exactly how from a quick look at grub2.

Marking is Triaged/Low; this won't be an issue for most people, we appropriately handle "usual" installations. It probably still needs to get fixed so that --bootloader-id works as expected, but bug 1242417 had some reasons for being fixed the way it was and I'll need to talk to Colin and/or Steve.

Changed in grub2 (Ubuntu):
status: New → Triaged
importance: Undecided → Low
Revision history for this message
oldfred (oldfred) wrote :

I changed GRUB_DISTRIBUTOR so I could tell which install was which.
I have my main working 14.04LTS install on sda, but install other test installs on sdb.
I try to install grub to ESP - efi system partition on sdb and installer even says installing to sdb. But it always installs to sda.
I then try renaming so I can keep them separate in UEFI.

All of these are grubx64.efi with different grub.cfg with different configfile entries for different UUIDs.

But they all use the one grub.cfg in /efi/ubuntu.

Revision history for this message
mr calvin (mrcalvin) wrote :

Another similar bug report 1247933

Im my case I have had big issues installing "new" hard disks or even USB flash drives, which also have the equal hardcoded "ubuntu" bootloader-id, and as you then have several disk with the same ID you have problems booting. As a main rule you should be able to name your bootloader something rather unique for each installation so future HDD mix want cause boot problems. Calling them all the same is in my experience a bad practice.

I really this could be fixed/up-prioritized.

I know time is limited resource for everybody, but having an option "--bootloader-id" that actually doesn't work for how maaaaany years is really critisable. At least remove the option from the documentation if knowone plan to fix it in the near future. A lot a people might waste a lot of time, I did for sure!

Revision history for this message
Ed A (goadeff) wrote :

grub-install --bootloader-id=customfoldername # <-- this is exactly what I wanted

it didn't work for me at first, but then I found this: - "... After running grub-install with --bootloader-id, run grub-install without any arguments. It will create an ubuntu entry. Delete it if you want to, but now your id is going to work "magically". Very annoying, seems to be an old bug. Hope I helps."

Revision history for this message
Eugene86 (eugene86) wrote :

I need to have two Ubuntu installations on my PC, and spent several hours in vain because of this bug reported 5 years ago -- needed to boot 10 times from liveusb to figure out what is wrong.
Please prioritize it!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.