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.