UEFI: how can I get GRUB installed from openSUSE listed by the Boot Manager?


This is a bit of a long story. I felt like installing Fedora Rawhide on my PC (read through this part; I am not here to ask for help with Fedora, more with the aftermath of me installing it), so I created a live USB for it using the 20180904 workstation live ISO and the dd command, to be precise I ran:

dd if=/path/to/iso of=/dev/sdc bs=4M status=progress && sync

then I rebooted. Usually when I reboot with a live USB inserted, press F9 (to show the Boot Manager, which lists available bootloaders; don’t confuse the Boot Manager with bootloaders like GRUB!), I see two USB-related options, one involves booting the USB in UEFI mode (with efivars loaded and alike), the other in normal mode. This was true with the Rawhide USB, I chose the UEFI mode initially, but it gave me:

(sorry for poor picture clarity; this image I’ll refer to as Figure 1). After this I naturally choose to boot the USB normally. Then I installed it, which went without hitch except it couldn’t install the bootloader (probably because I forced it to use my EFI partition, the default was to create a BIOS boot partition and non-UEFI /boot partition). I didn’t worry about the bootloader as I thought, “Well I can create a bootloader entry for it using GRUB installed by my other distros.” Then I rebooted, took the live USB out, pressed F9 and found this (which I’ll refer to as Figure 2):

. This really surprised me and irritated me because there used to be bootloaders belonging to the distros I had installed like Fedora, Arch Linux, openSUSE Tumbleweed, etc. listed here. What I did now was boot up my Fedora Rawhide live USB (which given I wasn’t running it in UEFI mode meant I couldn’t do anything with efibootmgr) and create a live USB for Zorin OS. Why Zorin? It has out-of-the-box support for my BCM4352 WiFi chip for starters, secondly I know its UEFI live session is nice and stable (and not likely to give me the error Rawhide did when I booted it in UEFI mode). What I did then was I ran (as root):

mkdir /tumbleweed
mount /dev/sda8 /tumbleweed
mount /dev/sda1 /tumbleweed/boot/efi # My ESP
mount /dev/sdb1 /tumbleweed/data
mount -t proc /proc /tumbleweed/proc
mount --rbind /dev /tumbleweed/dev
mount --make-rslave /tumbleweed/dev
mount --rbind /sys /tumbleweed/sys
mount --make-rslave /tumbleweed/sys
cp -L /etc/resolv.conf /tumbleweed/etc
chroot /tumbleweed /bin/zsh # My preferred shell

(these commands collectively I will refer to as (1)) then in the chroot I re-installed GRUB with:

grub2-install --target=x86_64-efi --efi-directory=/boot/efi /dev/sda

(a valid grub.cfg was already at /boot/grub). Then I typed:


to confirm that this had added an entry called “opensuse” to the Boot Manager and it had. Then I rebooted again, pressed F9 and I saw the above Boot Manager screen (i.e. Figure 2) again, with only those two options! The “opensuse” option that efibootmgr had shown was added by the grub2-install command wasn’t there! Then I rebooted the Zorin session, ran (1) and then in the chroot I ran:

efibootmgr --create --disk /dev/sda --part 1 --label 'openSUSE Tumbleweed' --loader /EFI/opensuse/grubx64.efi

(which is a command I learnt at an earlier thread of mine — https://forums.opensuse.org/showthread.php/532906-How-to-rename-UEFI-bootloader-entries?p=2879133) and rebooted. Yet again I was welcomed by two entry Boot Manager (the EFI file one and the notebook hard drive one), exactly like the one shown in Figure 2. This really ticked me off. I should warn you that I installed FreeBSD to /dev/sdb3, with /dev/sdb2 being its ESP partition. Having two ESPs didn’t create a problem before, however, so I don’t think this is related. I tried booting normally (without pressing F9) but I was welcomed by:

(Figure 3). This seems to be the “Notebook Hard Drive” option shown in Figure 2, as when I select it I get this. As for selecting the “Boot From EFI File” option in Figure 2 I get:

If I select this, select “efi” in the next menu (which is the only option given there), then I see three options: “boot”, “…” and “.” (I’m going to call this menu, menu 3). If I select “boot” and then “BOOTx64.efi” in the next menu it boots my FreeBSD 11.2 install. As it seems the /dev/sdb2 ESP was recognized by the “Boot From EFI File” option I decided to install my Arch bootloader there too (chrooted into it from an Arch live session, as I had a USB with it too, mounted up /dev/sdb2 to /boot/efi, ran grub-install and that was it), and luckily it appeared in the menu 3 and I was able to start Arch’s bootloader via it and boot openSUSE Tumbleweed from it. This workaround is good to have, but I would like my PC to automatically boot openSUSE on start up so I tried re-installing grub with grub2-install, hoping installing it from an actual (as opposed to live) system would allow grub2-install to create a GRUB install listed in the Boot Menu. I rebooted and found the menu shown in figure 2 again! Then I booted Tumbleweed again (using the Boot From EFI File method) and ran:

efibootmgr --create --disk /dev/sda --part 1 --label 'openSUSE Tumbleweed' --loader \EFI\opensuse\grubx64.efi

. Note how I replaced forward slashes with backslashes just in case since it’s a FAT32 partition (which was originally, to my understanding, a Windows file system) it required backslashes instead. I rebooted and yet again I was greeted by the Boot Menu shown in figure 2. I have tried reformatting /dev/sda1 with:

mkfs.fat -F32 /dev/sda1

then, in GParted, I set the appropriate flags for /dev/sda1 (boot, esp). Then I installed grub to it with:

grub2-install --target=x86_64-efi --efi-directory=/boot/efi /dev/sda

and just for good measure I created an additional menu item for Tumbleweed with:

efibootmgr --create --disk /dev/sda --part 1 --label 'openSUSE Tumbleweed' --loader \EFI\opensuse\grubx64.efi

(btw I have checked /boot/efi/EFI/opensuse/grubx64.efi exists and it does). Rebooted and still I saw Figure 2 again! So folks please tell you have a fix for this… I experience this issue before when installing Rawhide and I found replacing Rawhide with Fedora 28 (F28), by booting a live session for F28 and running the installer, fixed it. I don’t want to lose my Rawhide install so please tell me there’s another way to fix this.

Thanks for your time,

By another way I mean a non-destructive way, so please don’t suggest I install another distro, like openSUSE, instead on the Rawhide partition. If it helps here’s my /dev/sda partition table:

Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: D6295BA0-7C8B-4F33-BAF6-B6DF757614A6

Device          Start        End   Sectors  Size Type
/dev/sda1        2048     264191    262144  128M EFI System
/dev/sda2      264192   17041407  16777216    8G Linux swap
/dev/sda3    17041408  121899007 104857600   50G Linux filesystem
/dev/sda4   121899008  331614207 209715200  100G Linux filesystem
/dev/sda5   331614208  541337599 209723392  100G Linux LVM
/dev/sda6   541337600  741337087 199999488 95.4G Linux filesystem
/dev/sda7   741337088  838936575  97599488 46.6G Linux filesystem
/dev/sda8   941336576 1151051775 209715200  100G Linux filesystem
/dev/sda9  1151051776 1360766975 209715200  100G Linux filesystem
/dev/sda10 1360766976 1465618431 104851456   50G Linux filesystem
/dev/sda11 1570482176 1780197375 209715200  100G Linux filesystem
/dev/sda12 1780197376 1953523711 173326336 82.7G Linux filesystem
/dev/sda13  838936576  839516159    579584  283M Linux filesystem
/dev/sda14 1465618432 1570482175 104863744   50G Linux LVM
/dev/sda15  839516160  841611263   2095104 1023M Linux filesystem
/dev/sda16  841611264  941336575  99725312 47.6G Linux LVM

Partition table entries are not in disk order.

my /dev/sdb partition table is:

Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: BF46DA91-D996-4D1B-8063-82555036A18F

Device          Start        End    Sectors   Size Type
/dev/sdb1        2048 1660557311 1660555264 791.8G Linux filesystem
/dev/sdb2  1660557312 1660966911     409600   200M EFI System
/dev/sdb3  1660966912 1945769975  284803064 135.8G FreeBSD UFS
/dev/sdb4  1945769976 1953525133    7755158   3.7G FreeBSD swap

I am unable to read your first image (except the “to continue” bit). So lots of guessing.

The main problem is that you seem to have installed opensuse for legacy booting, while your system otherwise uses UEFI booting.

However, looking through all of your post, it looks as if your BIOS has now decided that it should only boot in legacy mode. I’m not sure why that happened.

For some versions of the BIOS (or, really, the UEFI firmware), this depends on the “pmbr_boot” flag. Maybe check whether that boot flag is set, and clear it.

From a bootable USB or similar:

parted /dev/sda print

and see whether it lists the “pmbr_boot” flag. And if it does, then google for hints on how to clear that flag.

Never knew squirrels could be so helpful, lol, thanks mate efibootmgr-generated boot manager entries now appear. pmbr_boot was set, but using parted I was able to remove it and now all is good.

I’m glad to hear it.