NB10 UEFI firmware bugs – boot order

The NB10 firmware is quite buggy. One area where this is apparent, is the configuring of boot devices.

At the end of the Linux install process, the installer runs the “efibootmgr” program to configure the firmware (what we used to call “BIOS”) to boot the new install. This involves a few steps:

  • Writing the new bootloader to the EFI partition.

Typically this partition is mounted under /boot/efi/ on a running Linux system with UEFI.

  • Adding a new EFI variable with information about the new bootloader.

EFI variables are items which are held in persistent storage (such as battery-backed RAM, or flash memory) by the firmware. Each possibility for booting the system (disks with bootloaders, configured USB ports, configured PXE-enabled NICs) has a variable associated with it.

  • Manipulate an existing EFI variable (the boot order) which contains instructions about what order to attempt the various options for booting the system.

We can also use the efibootmgr program to examine and change these variables. Note that there is some risk attached to this – it’s possible to render your system unbootable, and in extreme cases even brick (render permanently unbootable) your motherboard/laptop, using efibootmgr. This is because of bugs in those systems, and is not a flaw in efibootmgr.

The Toshiba firmware appears to ignore boot variables and ignore the setting of the boot order variable. The immediate effect of this, with BIOS 1.20, after installing Linux, is that at boot-time the system attempts all of the other boot methods (USB, PXE) before attempting to boot from the hard disk. This boot is in fall-back mode (ie boot/bootx64.efi) rather than for the file which was configured by the installer.

After installation we see:

# efibootmgr
Timeout: 2 seconds
BootOrder: 0000,2003,2001
Boot0001* UEFI: IP4 Realtek PCIe FE Family Controller
Boot0002* UEFI: IP6 Realtek PCIe FE Family Controller
Boot2001* EFI USB Device
Boot2003* EFI Network

Notably there are 3 entries for network boot even though we only have one NIC, none of the variables are relate to the hard disk, and the first item in the BootOrder (0000) doesn’t exist. Also, we should see BootCurrent (which one was booted last boot) and BootNext (which one will be booted on next boot), but both are absent.

On attempting to re-add the hard disk as a boot device (“efibootmgr -c -d /dev/sda -l ‘\efi\debian\grubx64.efi'”), we see:

# efibootmgr -c -d /dev/sda -l 'efi\debian/grubx64.efi'
Timeout: 2 seconds
BootOrder: 0000,0000,2003,2001
Boot0001* UEFI: IP4 Realtek PCIe FE Family Controller
Boot0002* UEFI: IP6 Realtek PCIe FE Family Controller
Boot2001* EFI USB Device
Boot2003* EFI Network
Boot0000* Linux

This is even stranger – we now have a duplicate entry in the BootOrder.
On reboot, the firmware still attempts to PXE before booting from the disk.

I’ve failed thusfar to have the firmware load a specified file from disk – it’s still booting from the fallback of ‘boot/bootx64.efi’ every time. All that I’ve managed to do is speed it up, by setting inactive the entries for the ethernet.

If the entries are removed, they re-appear on next boot.

 

Advertisements

8 thoughts on “NB10 UEFI firmware bugs – boot order

  1. True, i’m glad to see i’m not the only one to encounter that.
    Thank you for your blog, thanks to your help i’ve managed to boot my grub by renaming the efi file to boot/bootx64.efi

  2. Hello! I warn you that Toshiba has updated the bios (1.40) of the NB10 Series (avaialble on the website of TOSHIBA). The big surprise is that the UEFI now has a compatibility mode (“Legacy” / “CSM”) that allows you to ignore the constraint of UEFI. You can now start your linux USB key without fucking EFI files. Old school style.

    I’m sorry for my horrible English, I use Google translation 😀

  3. Hi Julien,

    Thank you for your comment. I downloaded and tried the new 1.40 BIOS, and wrote a new post for the blog about it.

    Your English is fine. No need to apologise.

    Cheers

      • I got it working :O

        I copied /EFI/Microsoft and /EFI/tools (blank directory) from my working older HDD and also my /EFI/BOOT/BOOTX64.EFI was all uppercase. I made that /EFI/Boot/bootx64.efi along with copying in those folders and it works perfectly now. Boots straight to my efivar choice and the SSD also now shows up in efibootmgr.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s