unable to persist bootloader id

Bug #1247933 reported by Shane O'Sullivan
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

I have more than one install of Ubuntu on my system and in order to distinguish them in the in the efi boot manager I install them with: grub-install --bootloader-id="Ubuntu 13.10 - DEV" replacing the bootloader id with a significant name for that install. However any update that triggers grub-install does not persist this naming scheme and returns to the default ubuntu name, making it impossible to distinguish systems.

Revision history for this message
Phillip Susi (psusi) wrote :

Rather than override it on the command line to grub-install, you should customize GRUB_DISTRIBUTOR in /etc/default/grub.

Changed in grub2 (Ubuntu):
status: New → Invalid
Revision history for this message
Shane O'Sullivan (hitsuji) wrote :

I had initially tried changing the value of GRUB_DISTRIBUTOR, however grub-update does not take this value as the bootloader id.

If you notice the default GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` produces "Ubuntu", however the default bootloader id is "ubuntu".

Revision history for this message
Phillip Susi (psusi) wrote :

It seems grub-install truncates the distributor at the first whitespace and converts it to all lower case. I'm not sure why this is, but it doesn't feel right. Maybe Collin can shed some light on it.

Changed in grub2 (Ubuntu):
status: Invalid → Confirmed
Changed in grub2 (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Lukas (lukas-ribisch) wrote :

grub-install, at least on 14.04 and 15.04, seems to hardcode the path "EFI/ubuntu" into all secureboot images. This has the effect that regardless of the boot entry that is selected in the EFI interface, grub always reads (ESP)/EFI/ubuntu/grub.cfg and continues to boot from the volume referenced there.

The binary /EFI/<bootloader-id>/grubx64.efi always contains the hardcoded string "EFI/ubuntu", which seems to be covered by canonical's signature and thus unchangeable.

If secure boot is deactivated, editing the grubx64.efi binary to reflect the correct path fixes the issue for me; i.e. if the bootloader is in EFI/mysecondubuntu, change EFI/ubunt2/grubx64.efi so that the string "EFI/ubuntu" becomes "EFI/ubunt2" (better keep the length the same in order to not break the binary alignment). This only works with secure boot disabled in the firmware; otherwise the signature becomes invalid.

However, when grub-install is invoked using --no-uefi-secure-boot, it gets even more confusing: grubx64.efi doesn't contain the hardcoded string anymore, but it seems as if grub.cfg is not even considered anymore – grub directly continues to boot from some hardcoded boot volume which I am unable to modify!

All of this makes it almost impossible to install two versions of Ubuntu on a single machine.

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

OMG....it this still an issue, so many years?
Using "--bootloader-id" doesn't work. Either remove the option or make it work!

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: https://askubuntu.com/questions/1129269/install-grub-using-custom-boot-loader-id-e-g-myubuntu - "... 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."

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.