Troubleshooting missing firmware access

UEFI firmware implementations

Some systems has a nasty habit of losing access to the firmware after your Linux installation. A couple of examples

This document is a work-in-progress ...

The cause

It is not clear what makes this happen - a lot is pointing to bad implementations of the UEFI specification - in some cases the firmware is hardcoded to load $esp/EFI/boot/bootx64.efi [wiki1]

Your system will usually be able to boot your installed Linux - only the firmware is not displaying correctly.

Usually you should be able to load the firmware on next reboot by using

$ systemctl reboot --firmware-setup

The cure

The first attempt to cure would be to reinstall grub - for an EFI system it goes like this

ESP=$(lsblk -no MOUNTPOINT | grep -e 'efi')
sudo grub-install --trage=x86_64-efi --efi-directory=$ESP bootloader-id=Manjaro --recheck
sudo grub-mkconfig -o /boot/grub/grub.cfg
sudo mkinitcpio -P

Next step is to check with LVFS if your firmware can be updated using Linux

Use https://fwupd.org to get familiar with the Linux Vendor Firmware Service. You can also search the database to verify if your system is supported.

There is no one-size-fits-all answer - the following is a list compiled from Manjaro Forum and the first being from Arch Wiki.

Read the Arch Wiki on UEFI and GRUB [wiki2] [wiki3] [wiki4]

I am listing the possibilities from least to most intrusive action.

  1. Use the most basic approach
    • Switch user to root su - - provide the root password when requisted
    • Copy the grub or systemd-boot efi stub to the $esp/EFI/BOOT/BOOTX64.EFI
    • Try booting to the firmware using the aforementioned command
  2. Removing the newly installed efistub
    • Boot your Linux system
    • Remove the grub efi loader - usually in a subfolder named for your distribution - e.g. $esp/EFI/Manjaro/grubx64.efi - rename the file or move it to another location
    • Try booting to the firmware
  3. Remove everything from the $esp mount point
    • This requires having some kind of boot media readily available to be able to do some system rescue.
    • This has proven to work on at least 2 occasions and requires you to have some experience using chroot to resque the system
  4. Using GRUB console to boot a removable media
    • This requires having some kind of boot media readily available and more intimate knowledge of the GRUB shell
    • It also requires the availability of either a Windows installation media or a dedicated rescue media like Hirens BootCD