3

I'm able to reinstall grub using default boot-loader ID "ubuntu"

But if I use custom name like "MyUbuntu" I cannot make a successful grub installation.

Test installation on a well-booting Ubuntu 18.04:

1: Delete existing grub:

rm -r /boot/efi/EFI/*

2: Install new grub:

grub-install --target=x86_64-efi --bootloader-id=MyUbuntu /dev/sda

2: Update grub:

update-grub

System now boots into the Grub console. The EFI was seeing the new boot entry in the boot menu just fine.

enter image description here enter image description here

Just took a peak into the /boot/grub/grub.cfg, it still says: menuentry 'Ubuntu' --class ubuntu.....

MrCalvin
  • 431

3 Answers3

2

After I ran into systemd-boot as boot-loader I've never looked back at GRUB. systemd-boot, is in my view, way more stable and has a much better way of configuration. And by "stable" I mean it's not as vulnerable as GRUB. GRUB is so easy to break. Just adding a new disk to your box can give you big trouble (because of maybe identical boot-loader ID's that you cannot change etc.)

Only downside of systemd-boot is the lack of secure-boot support, but that's not an issue for me, and that your kernel must be located in the EFI partition, instead of root partition, as it is the case with GRUP.

With systemd-boot I got back full control of the boot-process...YES

It should be the default boot-loader instead of GRUB.

UPDATE, How to do (Debian/Ubuntu):
(This is a rather superficially guide, but I hope it will get you started. Other sources: Arhlinux.., freedesktop.. and readme..)

1: First copy the kernel files from you root partition, e.g. /boot/vmlinuz-4.9.0-8-amd64 and /boot/initrd.img-4.9.0-8-amd64, to your EFI partition. You can place them in a subfolder of your choice or even in root-folder if you like.

2: Many guides says you need access to the EFI variables, but I'm not sure if this is needed. But to test if you have, run efivar --list.
To Install if missing: apt install efivar

3: Install systemd-boot loader to the EFI partition: bootctl --path=/mnt/efi install (use you own path to your mounted EFI partition)

4: Edit the file /mnt/efi/loader/loader.conf to something like:

timeout 5
# default 6a9857a393724b7a981ebb5b8495b9e-*

(haven't figured out how to use the auto-added UUID in the file, so I just marked it out)

5: Each file in /mnt/efi/loader/entries/*.conf correspond to at boot-entry in the systemd-boot menu. So to add your current OS make a file looking something like:

title      Debian 9 :-)
linux      /debian9/vmlinuz-4.9.0-6-amd64
initrd     /debian9/initrd.img-4.9.0-6-amd64
options    root=UUID=084917b7-8be2-4e86-838d-f771a9902e08`

(Modify the path to the kernel files you copied in step 1. Modify the UUID to the filesystem-UUID of you root partition (use Linux command lsblk -o name,uuid)

General info:
bootctl will install two bootloader-files in your EFI partition:

../BOOT/BOOTX64.EFI
../systemd/systemd-bootx64.efi

These files are identical. Your EFI bios on your motherboard moust boot/point to one of them. Either do it in the BIOS directly or use the Linux command efibootmgr....

To add a new boot entries just create a new /mnt/efi/loader/entries/*.conf files which point to the right kernel files and root partition.

The kernel files MUST be located on the EFI partition (FAT32).
The EFI partition must be sized accordingly. I think the kernel files for e.g. Debian/Ubuntu is about 50-60MB. So if you have two installations you need 120MB.

MrCalvin
  • 431
2

As mentioned by gdeff, to install Grub with a custom --bootloader-id, use also the option --no-uefi-secure-boot. For example:

grub-install                \
  --target=x86_64-efi       \
  --no-uefi-secure-boot     \
  --bootloader-id=MyUbuntu  \
  /dev/sda

Also, make sure that SecureBoot is disabled on your system.

Explanation

You only need to read the below (unfortunately lengthy) explanation if you want to better understand the interactions between grub-install, grubx64.efi, grub.cfg, and SecureBoot.

  • SecureBoot will only boot an .efi file that is cryptographically signed by Microsoft.
  • On an Ubuntu system, the file /boot/efi/EFI/ubuntu/grubx64.efi typically comes from one of two places:
  • Option 1: grubx64.efi is a static, unchanging, Microsoft-signed, SecureBoot-compatible “binary blob” Grub bootloader provided by Canonical. This is the default option.
  • Option 2: grubx64.efi is created on your system when you run grub-install. In this case, grubx64.efi is not signed and, therefore, is not compatible with SecureBoot.

With option 1 (Canonical-provided, SecureBoot-compatible grubx64.efi):

  • There will typically be two grub.cfg files.
  • Phase-1 grub.cfg at /boot/efi/EFI/ubuntu/grub.cfg
  • Phase-2 grub.cfg at /boot/grub/grub.cfg
  • The phase-1 grub.cfg file contains the information that grubx64.efi will need in order to find and read the phase-2 grub.cfg file.
  • The path for the phase-1 grub.cfg file, /boot/efi/EFI/ubuntu/grub.cfg, cannot be changed. Changing this path would require changing grubx64.efi itself. Changing grubx64.efi would invalidate the signature, rendering it incompatible with SecureBoot.

With option 2 (custom-made grubx64.efi):

  • There is no phase-1 grub.cfg file, because ...
  • All the configuration information that the custom-made grubx64.efi bootloader needs in order to find and read the phase-2 grub.cfg file (/boot/grub/grub.cfg) is embedded directly inside the custom-made grubx64.efi file itself.
  • This is possible because the custom-made grubx64.efi bootloader is not compatible with SecureBoot and therefore does not need to be signed by Microsoft.

If you run grub-install with --bootloader_id= and without --no-uefi-secure-boot, then:

  • grub-install will use the Microsoft-signed, provided-by-Canonical grubx64.efi file. (This is option 1, above.)
  • This grubx64.efi file and a custom-made phase-1 grub.cfg file will be installed in: /boot/efi/EFI/$bootloader_id/
  • However, upon boot, the grubx64.efi file will attempt to read /boot/efi/EFI/ubuntu/grub.cfg (as this path cannot be changed).
  • If /boot/efi/EFI/ubuntu/grub.cfg does not exist, then the boot will fail.
  • If /boot/efi/EFI/ubuntu/grub.cfg does exist, but comes from a different installation of Ubuntu on the same system, then the boot may fail, or grubx64.efi may boot that other Ubuntu system instead of the desired Ubuntu system.
  • Aside: In this case (i.e where --no-uefi-secure-boot is absent), it could be argued that: grub-install should generate an error (or at least a loud warning) rather than silently installing a very-probably-incorrectly-configured bootloader.

Alternatively, If you run grub-install with --no-uefi-secure-boot, then:

  • grub-install will create a custom-made (and unsigned) grubx64.efi file.
  • There will be no phase-1 grub.cfg file in /boot/efi/EFI/$bootloader_id/.
  • This grubx64.efi file will, all by itself, be able to find and read the phase-2 grub.cfg file at /boot/grub/grub.cfg.

As mentioned at the top of this answer, if you use --no-uefi-secure-boot, you will (of course) need to make sure that SecureBoot is turned off on your system.

mpb
  • 1,455
0

I use a simple workaround. 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.

dgow
  • 1