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
  • 413
  • 1
    I have a custom entry, but it really does not work as UEFI entry really uses /EFI/ubuntu/grub.cfg not my /EFI/Ubuntu_18_04/grub.cfg. So I only have one working UEFI entry and have to edit the grub.cfg in the ESP if I want to change default boot. And then I use grub to boot other installs. – oldfred Mar 28 '19 at 02:10
  • So is it a bug or by design? – MrCalvin Mar 28 '19 at 19:22
  • It is by design, but developers have for several years said they want to fix it. Obviously not a priority. – oldfred Mar 28 '19 at 20:28
  • Any workarounds? I need to have a non-default EFI folder? Been looking in the .cfg file but it didn't get me anywhere? – MrCalvin Mar 28 '19 at 20:47
  • I believe I saw someone who had two FAT32 formatted partitions and moved boot flag back & forth, changing which was ESP. But grub can boot any install you want either directly, chainload or configfile (load another grub). – oldfred Mar 28 '19 at 22:32
  • I wonder if you could just use a non-ubuntu version of grub-install e.g.boot from Archlinux live.iso. Maybe the bootloadèr-id will not be hardcoded into the .efi file.And if so, will Ubuntu boot at all? – MrCalvin Mar 31 '19 at 12:37
  • If you experiment let us know. I did try Fedora once, it allowed me to install directly to sdb, and found my Ubuntu installs. Did not try any other experiments – oldfred Mar 31 '19 at 14:00
  • It sure did work! :-) I used grub-install from Debian buster and my bootloader-id is now ubuntu2 I could imaging secure-boot might not work. It seems whole reason for Ubuntu hardcode the ID is the bootloader in signed and therefore cannot be modified, well you can, but then it would not be signed anymore. . But I don't use secure boot any way so I don't care. – MrCalvin Mar 31 '19 at 14:34
  • I use your method for years and I haven't any problem at all, for me it works out of the box. You say you don't use secure boot, but your menu entry points to shimx64.efi. My entries point to grubx64.efi (I don't use secure boot too). – mook765 Apr 21 '19 at 11:15

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
  • 413
  • I agree.....just limited time right now, but I'll add how in short words so people can get started – MrCalvin Apr 21 '19 at 12:00
  • I even did it on a USB flash. It has often been trouble full with GRUB. Now it should be easy to make an bootable USB key with multiple installation OS: Win10, WinSrv, Debian, Arch, Ubuntu etc.I always have my bag full of individual USB keys for each OS, now I can have one with good performance Mushkin Impact 64GB USB 3.0 (> 100MBs :-)) – MrCalvin Apr 21 '19 at 14:00
  • You can boot which ever Linux you like (You "normal" ubunto on HDD, Live for USB, any whould do. It doesn't even have to be the same distro. I assume all have the systemd-boot package available. You don't have to do all the painful chroot-thing as with GRUP. Just copy the kernel-files to EFI, install systemd-boot, modify/create the text-files, point EFI-bios to the need bootloader file....that's it :-) – MrCalvin Apr 22 '19 at 09:36
  • I doesn't matter, just boot any Linux. But if you boot from a USB you have to mount the EFI and root partition on the HDD to be able to access it. But if you boot your installed Ubuntu the EFI partition is already mounted to /boot/EFI. – MrCalvin Apr 22 '19 at 09:49
  • Nice :-) What error did you get? And which file did you point add for Win10...haven't tried that myself yet – MrCalvin Apr 24 '19 at 09:27
  • But which Win10 boot file did you point to in you entry file? – MrCalvin Apr 24 '19 at 10:04
  • title W10 efi /EFI/Microsoft/Boot/bootmfg.efi or similar. only two lines.. did not remember the path exactly.. now with phone – PRATAP Apr 24 '19 at 10:14
  • Yea, not so difficult to get running when you know how, haha – MrCalvin Apr 24 '19 at 10:23
  • I guess you can....(haven't tried either yet). – MrCalvin Apr 24 '19 at 10:27
  • Trying to "burn" Windows ISO to partition on USB flash-drive and create boot entry in systemd-boot EFI partition, thread link link. Making the utimate bootable multi-OS USB flash (Linux, Win10 in ENG and local languages, Win server etc). – MrCalvin May 09 '19 at 18:40
  • Hi, Sorry, I dont have any clue on this.. I have recently tried installing Ubuntu first without grub and then made Windows10 bootable USB from Ubuntu and Succesfully Installed Windows10 – PRATAP May 09 '19 at 18:41
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,355
  • Is there a way to persist the value that was passed to --bootloader_id=foo ? (and the use of --no-uefi-secure-boot) Because even minor updates to grub can trigger a grub-install with default values. So the answer is only partially complete if the setup isn't persistent. (still very useful for a user that can deal with fixing grub from time to time) – tuxayo Jan 08 '24 at 20:08
  • @tuxayo - There may or may not be a way to persist the value of --bootloader-id and --no-uefi-secure_boot. I don't know. The only time I can remember Grub failing for me is after I did an in-place upgrade from Ubuntu 23.04 to 23.10. (I almost never do in-place upgrades.) I wondered why Grub failed, but did not investigate. I just reinstalled Grub manually. Your comment may explain why that failure happened. The maintainers of the Debian/Ubuntu grub packages might know the answer. – mpb Jan 10 '24 at 06:36
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
  • 3
    this will appear to work, but if "ubuntu" entry is deleted then the custom bootloader-id will not work. No need to re-run grub-install without params; just disable uefi secure boot and run grub-install --bootloader-id=myid --no-uefi-secure-boot

    See Booting multiple Ubuntu versions with EFI

    – gdeff May 18 '20 at 00:56
  • @gdeff you saved the day! thanks :) adding --no-uefi-secure-boot generates a different grubx64.efi file, which works around the problem of missing EFI/ubuntu folder – Tomeg Mar 23 '22 at 16:14
  • Then you have to disable 'secure boot' in UEFI ( what some people incorrectly still call BIOS ). – Joepie Es May 05 '22 at 23:28