I just updated the UEFI for my mainboard (MSI MPG B550 Gaming Plus), but since the update I am not able to select grub for booting in the UEFI settings. Only the windows Bootloader is shown.
I already deactivated secure boot (again) after the upgrade and checked all other mainboard settings. But I don’t think I did any software-side changes at the same time as the update.
Currently I run Manjaro by starting a Live-USB, selecting “detect UEFI Bootloaders” in the “Live” Grub, and from there I can start /efi/Manjaro/grubx64.efi. All OS are installed on the same (NVME-) Drive on the PC.
sudo efibootmgr -v doesn’t find the grub partition, it only shows the Windows Boot Manager and the USB Live system I am booting off as a workaround.
Do I need to completely reinstall Grub according to this article? GRUB/Restore the GRUB Bootloader - Manjaro
Or is there some simpler way to fix this? I don’t really want to set the windows bootmanager to boot into grub ( bcdedit /set {bootmgr} path \EFI\manjaro\grubx64.efi), since I expect windows to just break my boot during future updates like that.
Yes and no. There are a few steps that can be done more easily. First of all, you don’t need to reinstall the grub package with pacman. Secondly, you can commonly get away with update-grub instead of “grub-mkconfig -o /boot/grub/grub.cfg”.
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-6.6-x86_64
Found initrd image: /boot/amd-ucode.img /boot/initramfs-6.6-x86_64.img
Found initrd fallback image: /boot/initramfs-6.6-x86_64-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
Root filesystem isn't btrfs
If you think an error has occurred, please file a bug report at "https://github.com/Antynea/grub-btrfs"
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
Found memtest86+ EFI image: /boot/memtest86+/memtest.efi
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
done
but after the update the uefi still doesn’t list grub as a boot option
You might like to try those commands again from a chroot environment.
manjaro-chroot -a
This should mount / and let you work (as root) as if on your own system (even though you booted from Live media). After that, you would usually need to boot to BIOS and select Manjaro OS as first in boot order.
I am not running a live system, I am just using the live USB to boot into the “live” GRUB. There I am using the “Detect EFI bootloaders” option to boot into my “installed” GRUB.
So I would think that update-grub runs on the correct GRUB installation. Or should I still do the manjaro-chroot? The program is also not installed on my manjaro installation
I just reinstalled GRUB following the “Restore the GRUB Bootloader” guide and this has fixed the issues.
Now I am just left wondering:
Are installed Bootloaders connected so intimately to the system that just a UEFI update causes breakage? I never experienced this on one of my previous computers
Should I expect GRUB to break on every future Update of the UEFI?
Why doesn’t the windows bootloader break in the same way when updating the mainboard? (Probably because everyone only tests on windows)
Thank you all for your assistence. I was a bit scared of completely reinstalling GRUB, since my Backup-Drive is off-site and I didn’t want to risk having to restore one.
They arent ‘intimately connected’
They reside in directories accessible by your EFI, and the EFI also has mechanisms for writing tables of bootloaders. It can of course also modify those entries.
Your entry was just unregistered by the firmware.
Not every one. But its possible on any of them.
Then again … so is a bad EFI update that actually factually bricks your machine.
The vendor can do all sorts of crazy stuff, which brings us to the final points …
Could be anything from the way the upgrade is written to some logic like ‘Machine with windoze preinstalled continues to recognize OEM install during upgrades but discounts others’ - again due to anything from actual contractual agreements down to technical ineptitude and beyond.
Using entirely different disks would not necessarily avoid the same outcome.
For what its worth - I have never used more than a single disk for personal multiboots and I have only had to deal with this a handful of times.
This is entirely dependent on the oem/motherboard/uefi manufacturer. Some do, some do not reset…
Should I expect GRUB to break on every future Update of the UEFI?
If you have the type that resets to default settings, it will do. Do not update the uefi if you do not have the manjro usb at hand. As you can read above, i found this a bit inconvenient and try to find alternative.
Why doesn’t the windows bootloader break in the same way when updating the mainboard?
That depends. The cynic answer is, WIN-INTEL Cartel tries to bribe or extort the OEM “Partners” and monopolize the market. Something like “Hi Lenovo Pals, do you want the latest Intel CPU 6 months before everybody else? Well that is easy, just make sure at least 60% of your laptops are with intel cpus. If you decide that half or less will be with our cpus, you will fall into our non-priority partner category and you will NOT be allowed tto buy he newest cpu model for another 6 months”
A similar game with windows…we see it for example with the new s2idle standby mode, developed from microsoft,or the secure boot, they actually had a lot of influence in the development of uefi. i can imagine some UEFI manufacturers have the windows entry as part of default settings so that it survives the reset. Or, the fallback EFI file is windows one and after a reset is done the system boot from it. But default manjaro writes its own efi file and does not touch the fallback one. I guess this theory can be tested but i was too lazy to bother. (Basically it will be the procedure to restore grub with some modified parameters in the command).
My MSI board loses my Manjaro UEFI entry after every UEFI update, unless I add ---removable to my GRUB install command. This installs the entry under /boot/efi/EFI/BOOT/BOOTX64.EFI. Without it, it goes under /boot/efi/EFI/manjaro/grubx64.efi, which will get removed by MSI’s updates.
Note: I have no idea whether using --removable has ill effects on dual-boot systems or such. Manjaro is the only operating system I have on this machine.
$esp/EFI/BOOT is the UEFI fallback location. The theory is that no players will overwrite the efi loader in the fallback location, so, placing the files from say $esp/EFI/Manjaro into $esp/EFI/BOOT will ensure it’s never overwritten.
I’ve never used --removable; in fact I’d forgotten it even existed. The rEFInd Bootloader’s refind-install is able to achieve the same result by moving the rEFInd files to $esp/EFI/BOOT.
If you want a certain bootloader to absolutely be default every time, then moving that loader to the fallback location will make it happen. There are some distributions that consistently set themselves as first in boot order (yes, I’m looking at you, Mr. Debian) at every major update (or when GRUB is updated). This will prevent that, for anyone who plays by the rules…
