Drive not bootable after BIOS update

Framework Laptop 13
1

I have a DIY Framework with the 2TB SN750 WD Black with Arch Linux installed. After updating the BIOS to 3.07 using the BIOS 3.07 EFI Shell update, the SSD no longer shows up as a bootable drive.

Strangely, it still shows up as an attached device under the Boot tab in the BIOS and if I boot through a USB and mount the drive it looks like all my files are still there, so it doesn’t look like drive corruption. I even tried taking the drive out and plugging it back in and it still doesn’t show up.

I have secure boot turned off but the drive doesn’t show up on the boot menu for me to even attempt to boot from it. I’ve reinstalled the 3.07 BIOS updates multiple times, so I don’t think it was a bad install. Anyone have any ideas how to fix this?

2

You’ll need to restore the config for whatever bootloader you’re using, whether that’s grub or something else (in my case, booting from a usb and reinstalling refind fixed things).

2 Likes
3

For example, you can download Super Grub2 Disk to create a recovery USB flash drive:

Then write it using dd to a USB flash drive:
sudo dd if=super_grub2_disk_hybrid_2.04s1.iso of=/dev/sdc bs=4M; status=“progress”

Boot using the Super Grub2 USB flash drive you just made.
Select the appropriate EFI file to boot your distro from.
Log in like you normally would.
Open a terminal.
Reinstall grub-efi.

For example, on Debian (obviously for Arch use pacman instead of apt):
sudo apt-get install --reinstall grub-efi
sudo grub-install
sudo update-grub

Check the EFI boot options:
efibootmgr -v

If the first boot option listed is your distro on your internal drive then:
reboot

You should now have a fixed grub-efi that will boot your distro without need for the Super Grub2 disk, thereby fixing the borked grub-efi parameters mismatch.

2 Likes
4

System: Arch Linux / BTRFS with Luks
Secure Boot: disabled
Upgrade to 3.07 succeeded.

After reboot the system fails to recognize any boot records on SSD.
Anyone in the same boat?

5

There’s a number of reports of the update to 3.07 resetting your settings and clearing your boot entries over in the official update thread, BIOS 3.07 + Windows 10 and (11 Alpha) driver bundle - #78 by Val.

You will probably need to boot recovery media and reinstall your bootloader.

2 Likes
6

@DHowett , thanks. Yes, I figured out that the Bios 3.07 “Windows” thread was not just Windows and had some reports about issues. I actually just managed to repair it. Took a bit longer with all BTRFS/crypto subvolumes, but simple grub-install was enough.

If anyone has similar issue - here is the good reference. Obviously adjust to your filesystem specifics. Then chroot and just grub-install was enough for me.

Cheers

1 Like
7

The files aren’t actually removed from the EFI partition, their boot options are just wiped from NVRAM.

I followed the NVRAM-editing part of the manual rEFInd instructions on the Arch Wiki to fix my rEFInd-not-found problem. Below is the (genericised) efibootmgr command, taken from that page:

# efibootmgr --create --disk /dev/sdX --part Y --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --verbose

If you’re going to use it, make sure you fill in the correct device, loader path (relative to the EFI partition’s root – it should be correct for rEFInd) and label, of course

1 Like
8

Running into no boot disk issue after bios upgrade. Reinstalling grub-efi, following GrubEFIReinstall - Debian Wiki with grub-install and update-grub, worked for me.

2 Likes
9

Same here on Arch. Just boot from the arch install media, mount your partitions, chroot and re-run grub-install command, which will add the efi entries again. Just another way, to achieve the same thing.

1 Like
10

On GRUB’s Arch Wiki page, it says:

Tip: If you use the option --removable then GRUB will be installed to esp/EFI/BOOT/BOOTX64.EFI (or esp/EFI/BOOT/BOOTIA32.EFI for the i386-efi target) and you will have the additional ability of being able to boot from the drive in case EFI variables are reset or you move the drive to another computer.

I’m pretty confident that the BIOS updates are wiping things entirely, so GRUB users could pass this flag to ensure that there’s still a copy that doesn’t need to be registered with EFI (which is how you do it normally) and avoid this problem for good. Windows/systemd-boot don’t have this problem, others may not either.

2 Likes
11

@acridwax Thanks! Fixing it from a recovery drive was giving me tons of trouble, your solution worked perfectly.

1 Like
12

I’m running Linux MInt and had that problem after updating to BIOS 3.07. I pressed F12 on Boot in order to get into various options in efi. The Windows boot manager was first in the order, so I chose the “ubuntu” choice which is the grub option. This gave me GRUB and I was in. Once Linux had booted I ran ‘sudo grub-install’ to make sure that GRUB was the default boot loader again.

I had tried looking at the BIOS first, and found where the options in efi were listed, but there was no way I could see to change the order there. Seeing both options listed gave me the idea to try the F12 boot options possibility.

Edit: It may be obvious, but I forgot to mention that I have dual boot and did the BIOS update in Windows. Perhaps doing it from Linux will avoid this problem.

1 Like
14

In case it’s helpful for someone, this is a custom script I use to install my EFISTUB kernel to boot:

#!/bin/bash
set -ueo pipefail

# Remount EFI partition read/write and restore to readonly when done

trap 'mount /sys/firmware/efi/efivars/ -o ro,remount &>/dev/null || true' EXIT
mount /sys/firmware/efi/efivars/ -o rw,remount &>/dev/null || true

# Remove all existing Arch Linux entries

efibootmgr | grep 'Arch Linux' | grep -Po 'Boot\K\d+' | while read bn; do
  efibootmgr --delete-bootnum -b "$bn" &> /dev/null
done || true

# Add new entry

_linux="linux-hardened"
_crypt="cryptdevice=UUID=00000000-0000-0000-0000-000000000000:root:allow-discards"
_root="root=UUID=00000000-0000-0000-0000-000000000000"
_initrd="initrd=\\intel-ucode.img initrd=\\initramfs-${_linux}.img"
_misc="rw overlay.metacopy=N nvme.noacpi=1 mem_sleep_default=deep"
_security="apparmor=1 lsm=lockdown,yama,apparmor,bpf security=apparmor"
_temp=""

efibootmgr --verbose \
  --create --disk /dev/disk/by-id/nvme-WDS00000000-000000_00000000000 --part 1 --label "Arch Linux" \
  --loader /vmlinuz-${_linux} \
  --unicode "${_crypt} ${_root} ${_initrd} ${_security} ${_misc}${_temp}"
1 Like