I ran zypper dup on my Tumbleweed system a couple of hours ago. I just rebooted and when it gets to Grub then I get dumped to the recovery shell with the message “symbol grub_parser_execute not found”.
I’ve reinstalled all of the Grub packages to try and force it to rebuild initrd etc and reinstall itself, but that didn’t work. But none of the Grub packages have changelog entries after mid-August, so it is unlikely that it’s a change in that. I guess a kernel update was more likely?
Are there any known issues? I can find lots of other “symbol not found” messages on various distros, but not this one.
(If anyone else hits this and wants a workaround then I can’t help much - I’m currently bypassing Grub by using a 2017 Tumbleweed installer DVD and picking “Boot from HDD” from its boot menu )
sudo grub2-mkconfig -o /boot/grub2/grub.cfg didn’t fix it.
But I just discovered that there’s two instances of openSUSE in the UEFI boot list when I force the BIOS to let me choose a boot device. And the second one works!
So, it seems like something changed in my UEFI setup and added a new entry, the old one is broken, and the old one was still the default?
Sorry, I wasn’t clear. I know the boot process and that Grub is the bootloader before you hit the kernel (I’ve been using Linux since the times when “Grub or LILO?” was a thing). I just thought that maybe a kernel or kernel module update had triggered a reinstall of Grub in the UEFI list/boot partition that had gone wrong in some way (bad options or something).
Now that I’ve fixed it via the BIOS (which was tricky with the two identically named entries, because it kept thinking that I hadn’t changed anything!) then efibootmgr gives me:
The -v flag adds some hex dumps that are identical after the first 42 bytes (the first slash).
I managed to disable the “wrong” one. I’ve not deleted it yet in case I can still debug a “why”. It would have been less worrying if I could have renamed one of them, but that doesn’t seem to be an option, and I didn’t get Grub to install itself with a new name in the UEFI list either.
I’ve just worked out that the UUIDs aren’t /dev/disk/by-uuid but /dev/disk/by-partuuid.
The working UUID is SDA1. The broken boot entry is SDA4. Which is weird, because SDA4 is the extended partition. I don’t know why the system (or me) would ever have installed the bootloader there. My OS is on LVM on an NVMe, but I guess the separate disk might be necessary with UEFI boot partitions rather than MBR (or I’d have lost space on the NVMe)
Ah, legacy knowledge from the MBR days mount is showing SDA1, 2, 3 and 5 but not 4, so that’s where my mind jumped to.
I thought it wasn’t showing in GParted either, but I’ve just noticed that it is and it comes before SDA3. It’s a 265MB FAT16 partition, which fits for a UEFI boot partition. Only 6MB used, though. GParted names it “primary”. SDA1 is the one that is mounted as /boot/efi.
Some of the stuff in that partition is a little old!
That depends on the BIOS. Some older BIOS cannot use NVME drives during boot.
On my current desktop, the EFI partition is on the NVME drive. I do have a secondary EFI partition on a hard drive, but normal booting uses the EFI partition on the NVME drive.
It is an option. Add a string value that is not “opensuse” to GRUB_DISTRIBUTOR= in /etc/default/grub. Following next bootloader update, you should find that new string in efibootmgr output and as a new directory in /boot/efi/EFI/. You may want or need to remove the old duplicate from /boot/efi/EFI/, once you determine which of the duplicates your new string replaced.
From a quick search in /etc, it looks like I’ve been updating the same install since October 2017! So it’s not an NVMe thing, it’s probably a combination of “/boot couldn’t be in LVM” and “maximising the SSD usage for things that need to be fast (OS) rather than rarely used things (initial bootstrap and documents)”.
I already tried that yesterday after finding other people with distro confusion (e.g. Ubuntu on the HDD and Ubuntu on a removable disk) and then I ran sudo grub2-mkconfig -o /boot/grub2/grub.cfgand it didn’t change anything. Is it another command to force Grub to build in a way that updates the list?
$ grep DISTRIBUTOR /etc/default/grub
GRUB_DISTRIBUTOR="goodSUSE"
$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-6.11.0-1-default
Found initrd image: /boot/initrd-6.11.0-1-default
Found linux image: /boot/vmlinuz-6.10.11-1-default
Found initrd image: /boot/initrd-6.10.11-1-default
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done
$ efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001
Boot0000* opensuse HD(1,GPT,[UUID],0x800,0x81000)/File(\EFI\OPENSUSE\GRUBX64.EFI)
Boot0001 opensuse HD(4,GPT,[UUID],0x70a81800,0x84800)/File(\EFI\OPENSUSE\GRUBX64.EFI)0000424f
I also tried setting it with efibootmgr but apparently its -L flag only works when creating an entry and it won’t edit one.
Okay, grub2-mkconfig only does the stuff in /boot. sudo grub2-install /dev/sda1 (set the right partition as appropriate) seems to set up a new entry and uses the distributor value.
Now maybe I can change the default to the new entry (0002) and delete the old ones. Then I have to see whether I can update the entry to get a “normal” name again or whether it will create a new one. I might need --bootloader-id=ID, assuming it’s talking about the numbers in efibootmgr output.
keep in mind that if you want to keep 9 kernel versions as exampled above, you will need a significantly larger /boot/efi partition than the default 500MB.
I’d have to check, but I think I’ve normally got two kernels installed at once - currently it’s 6.10.11 and 6.11.0. The 256MB boot partition has been working fine for me for years.
That would be true if using “systemd-boot” for booting. In that case, the kernels and initd files are in the EFI partition.
However, with grub for booting, the kernel and initrd files are in the root partition or in “/boot” if you have a separate file system for that. Nothing in my EFI partition changes with a kernel update. Yes, “grub.cfg” changes, but that is not in the EFI partition.
)