A few months ago, I got given a laptop with a very interesting condition. The BIOS setup menu was supposedly inaccessible, and nothing apart from the default boot option works. Time to investigate to see what is actually happening and what we can do about it.

The status quo

When starting the laptop without doing anything special, the default option boots just fine, as expected. However, while pressing F2 during boot causes a beep tone, it ends up falling through to the same behavior as if nothing was pressed. On the other hand, pressing F12 lands us in a very empty boot menu:

This, obviously, is not good. The boot menu should (at least) show all bootable UEFI devices in addition to the boot entries that have been created manually.

Of course, the first thing that one would try is to reset the BIOS settings. Since the CMOS battery is quite hidden behind plastic shielding, I instead bridged the CL1_CL2 test point that is located under the RAM slot.

After the BIOS reinitialized, the boot menu looks like the following:

The manually created boot option is now gone, and device-based boot options show up instead. However, trying to enter the BIOS setup menu still shows the same fallthrough behavior as it did before.

Luckily, there now is the option to boot from USB storage, so the BIOS flash utilities provided by Fujitsu are a possibility going forward. Note that (at least for the AH532) there are multiple hardware revisions, so I had to go through the device serial number to arrive at the correct set of downloads.

After flashing the BIOS and rebooting, the boot menu looks normal and pressing F2 to enter the BIOS setup menu works like a charm:

Isolating a reproducer

Now that I was back in a working setup, the first thing I did was to make a backup of the current configuration. For that, I made an image of the Winbond 25Q32BVSIG SPI flash chip that is marked as “U35” on the motherboard, as it contains the whole UEFI PI firmware volume including executable code and data storage. Whenever something is broken, I can now just flash back the image instead of going through a full reset-CMOS-and-update-firmware cycle.

For easier testing, I also wanted a better reproducer than “reinstall your distribution of choice”. Therefore, I tried the first thing that came to mind, and it immediately broke the boot menu again:

# efibootmgr -c
BootOrder: 0000
Boot0000* Linux

Warning: Do NOT run this command twice. Doing so made the boot menu completely inaccessible.

Excursion: UEFI boot entry handling

At a high level, UEFI stores data in a large key-value store that is collectively called “UEFI variables”. Included in those variables are (among other things) boot entries and related settings. Variable access is done through standardized interfaces that are documented in the UEFI specification.

Boot entries are stored in entries named BootXXXX, where XXXX is a four digit hexadecimal number. Boot option order is determined through the BootOrder entry, which lists all four digit hexadecimal numbers in the order that they should appear in.

On my Framework laptop, the boot entries are set up as follows:

BootOrder: 0002, 0001, 2001, 2002, 2003
Boot0001: "Windows Boot Manager"
Boot0002: "GRUB"
Boot2001: "EFI USB Device"
Boot2002: "EFI DVD/CDROM"
Boot2003: "EFI Network"

Putting the pieces together

Suddenly, the efibootmgr -c output above doesn’t look all that confidence-inspiring. The command is supposed to create a new entry and insert it at the top of the boot entry list, but it ended up clearing the entire list instead. Running efibootmgr on a fresh boot also doesn’t result in quite the expected output:

# efibootmgr -v
Could not read variable 'BootNext': No such file or directory
Could not read variable 'BootCurrent': No such file or directory
Could not read variable 'BootTimeout': No such file or directory
Could not read variable 'BootOrder': No such file or directory
No BootOrder is set; firmware will attempt recovery
Could not read variable 'MirrorCurrent': No such file or directory
Could not read variable 'MirrorRequest': No such file or directory

It appears that Linux is unable to read existing variables from storage, which is immediately confirmed by inspecting the source of truth:

# ls -al /sys/firmware/efi/efivars/
total 0
drwxr-xr-x 2 root root 0 Jan 15 16:09 .
drwxr-xr-x 5 root root 0 Jan 15 16:09 ..

Note: At this point, I checked that Windows and various other UEFI tools are able to read the variables just fine, so Linux’ output is confirmed to be incorrect.

Now, this explains why the custom boot entries and the device-based boot entries end up being gone. efibootmgr can’t find any existing boot entry setup and just assumes that it can create a new setup without repercussions.

But why does it make the BIOS setup unusable? Using UEFITool, I inspected the flash image I made earlier, and reconstructed the following entries:

BootOrder: 000E, 000D, 0006, 0007, 0008, 0009, 000A, 000B
Boot0000: "BIOS Setup"
Boot0001: "Boot Menu"
Boot0002: "Diagnostic Screen"
Boot0003: "Recovery and Utility"
Boot0004: "Diagnostic Program"
Boot0005: "Diagnostic Progrogram ROM"
Boot0006: "Floppy Disk Drive"
Boot0007: "Drive0 HDD"
Boot0008: "CD/DVD Drive"
Boot0009: "NETWORK"
Boot000A: "USB HDD"
Boot000B: "USB CD/DVD"
Boot000C: "Erase Disk"
Boot000D: "Windows Boot Manager"
Boot000E: "proxmox"

Oh, no…

“BIOS Setup” is an actual boot menu entry.

And it gets overwritten by the new boot entry that gets placed erroneously.

Note: Attentive readers might have noticed the reason for why everything breaks completely when running efibootmgr -c twice: The second boot entry that is created would be Boot0001, which successfully replaces “Boot Menu”.

Creating a temporary band-aid

Now that I knew what went wrong, I was able to create a small program that resets the boot order, as well as the BIOS setup and boot menu entries to their expected contents.

Note: This program is based on an UEFI dump of a Fujitsu LIFEBOOK AH532 (YLKV). It is unlikely that it will work on any other hardware (revision) that happens to have the same symptoms. Furthermore, the written data may also be dependent on the firmware revision, so take caution when running this on a firmware version that is not v1.08 or v1.09.

Warning: I assume no liability for broken hardware or software due to correct or incorrect usage of this tool.

#include 

uint32_t boot_attributes = EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS;

unsigned char bootorder_data[] = {
    0x06, 0x00, // Boot0006
    0x07, 0x00, // Boot0007
    0x08, 0x00, // Boot0008
    0x09, 0x00, // Boot0009
    0x0A, 0x00, // Boot000A
    0x0B, 0x00, // Boot000B
};

unsigned char boot0000_data[] = {
    0x00, 0x01, 0x00, 0x00, // Attributes
    0x18, 0x00,             // FilePathListLength

    // Description: "BIOS Setup       "
    0x42, 0x00, 0x49, 0x00, 0x4F, 0x00, 0x53, 0x00, 0x20, 0x00, 0x53, 0x00, 0x65, 0x00, 0x74, 0x00, 0x75, 0x00, 0x70, 0x00, 0x20, 0x00, 0x20, 0x00, 0x20, 0x00,
    0x20, 0x00, 0x20, 0x00, 0x20, 0x00, 0x20, 0x00, 0x00, 0x00,

    // FilePathList[0]
    0x04,       // Type: Media Device Path
    0x06,       // Sub-Type: PIWG Firmware File
    0x14, 0x00, // Length: 4 + 0x14
    0x66, 0x8B, 0x1C, 0x72, 0x6C, 0x42, 0x86, 0x4E, 0x8E, 0x99, 0x34, 0x57, 0xC4, 0x6A, 0xB0, 0xB9,

    // FilePathList[1]
    0x7F,       // Type: End of Hardware Device Path
    0xFF,       // Sub-Type: End Entire Device Path
    0x04, 0x00, // Length: 4

    // OptionalData (empty)
};

unsigned char boot0001_data[] = {
    0x00, 0x01, 0x00, 0x00, // Attributes
    0x18, 0x00,             // FilePathListLength

    // Description: "Boot Menu"
    0x42, 0x00, 0x6F, 0x00, 0x6F, 0x00, 0x74, 0x00, 0x20, 0x00, 0x4D, 0x00, 0x65, 0x00, 0x6E, 0x00, 0x75, 0x00, 0x00, 0x00,

    // FilePathList[0]
    0x04,       // Type: Media Device Path
    0x06,       // Sub-Type: PIWG Firmware File
    0x14, 0x00, // Length: 4 + 0x14
    0x40, 0x84, 0x48, 0x86, 0xBB, 0x41, 0xC7, 0x42, 0x93, 0xAC, 0x45, 0x0F, 0xBF, 0x77, 0x66, 0xBF,

    // FilePathList[1]
    0x7F,       // Type: End of Hardware Device Path
    0xFF,       // Sub-Type: End Entire Device Path
    0x04, 0x00, // Length: 4

    // OptionalData (empty)
};

int main() {
    int rc = efi_set_variable(EFI_GLOBAL_GUID, "BootOrder", bootorder_data, sizeof(bootorder_data), boot_attributes, 0644);
    if (rc  0) {
        efi_error("Resetting BootOrder failed");
        return 1;
    }

    rc = efi_set_variable(EFI_GLOBAL_GUID, "Boot0000", boot0000_data, sizeof(boot0000_data), boot_attributes, 0644);
    if (rc  0) {
        efi_error("Resetting Boot0000 failed");
        return 1;
    }

    rc = efi_set_variable(EFI_GLOBAL_GUID, "Boot0001", boot0001_data, sizeof(boot0001_data), boot_attributes, 0644);
    if (rc  0) {
        efi_error("Resetting Boot0001 failed");
        return 1;
    }
}

Naturally, this isn’t a great solution, since users will continue to brick their installations initially, just like they did for the last 10 years. However, this is everything that I managed to research so far, and the band-aid fix makes it reasonable for publication.

I will look into fixing this properly at some point in the future, and if I manage to do so this post will probably get a part two, so stay tuned. (Apparently Jekyll supports RSS?)