Why does my uefi firmware ignore the boot order?

Question

My Toshiba Tecra R950 supports UEFI, mostly. It has a good old-fashioned text-based blue firmware settings system that it refers to as "BIOS", rather than the fancy graphical setup most proper UEFI systems have. The boot order menu (either in setup or when I bring it up at boot time by pressing F12) doesn't allow selection of operating systems, only devices. The system seems to be unable to boot unless the efi partition contains a fallback loader at /efi/boot/bootx64.efi – although according to what I've read this should only be necessary for removable volumes.

The Linux efibootmgr tool can be use to access or modify the actual efi boot priority (in terms of what operating system to load first) but the firmware ignores whatever you set here when it boots and instead relies on the hardware priority set in the BIOS/firmware setup and uses the fallback loader found on the first accessible volume. The one exception to this seems to be when resuming from S4 (hibernate), it suddenly looks to this list and boots the top loader there rather than the fallback loader.

Is this just a case of a bad implementation of UEFI? Is it possible to have a hybrid BIOS/UEFI with only limited support of UEFI features? Since my system seems to know how to deal with the boot priority on resume from S4, is there any way I can make it work in general?

Answer 1

Short answer: Based on your description, I think your firmware is defective.

Long answer: First, the EFI (or UEFI, which is just EFI 2.x) specification says NOTHING about user interfaces. Thus, you can build a purely text-mode EFI user interface that's still 100% compliant with the EFI/UEFI spec. BIOS doesn't have an official spec, but there have been attempts at graphical setup utilities for BIOSes. Thus, you should not use a graphical setup utility, or lack thereof, as an indicator of whether something is an EFI or a BIOS, or of how "complete" an implementation is. The eye candy is completely irrelevant to the point, and to your question.

As a side note, many manufacturers refer to their EFIs as BIOSes. IMHO, this is bad practice, because it creates confusion in users' minds about the distinction between the traditional 16-bit BIOS and modern 32- or 64-bit EFIs, which are very different in most important details.

That said, the EFI spec is pretty clear that the boot order variables (which are set via efibootmgr in Linux) should be honored. If your firmware is ignoring those variables, then it's in violation of the spec. Unfortunately, such violations remain distressingly common, although they were more common a few years ago. A quick Google suggests that your model may have been introduced in 2012, so it may not be surprising that it's got an old and flawed EFI. You might want to check Toshiba's Web site to see if there's a firmware update available. That might or might not fix anything, but it's definitely worth checking.

You might also try using a tool other than efibootmgr, such as EasyUEFI in Windows or bcfg in an EFI shell. In theory, any of these tools should do the job. In practice, I've observed that efibootmgr sometimes fails when other tools work.

As for a "hybrid BIOS/UEFI," such things do exist. I know of two broad categories:

• EFI atop BIOS -- The EFI spec doesn't cover some of the lowest-level hardware initialization features. To handle this task, some early EFIs for x86/x86-64, such as Gigabyte's Hybrid EFI, used a traditional BIOS, putting the EFI "above" that. My one experience with that (described in the link) was painful, but that may have had more to do with the implementation than the general approach. AFAIK, this approach has been abandoned in favor of other hardware-initialization code that interfaces better with the EFI above it.
• EFI locked into CSM -- The Compatibility Support Module (CSM) is an optional EFI feature that enables the EFI to boot old BIOS-mode boot loaders. I've heard claims that some "BIOSes" in the last years of BIOS-based computers actually used EFIs with their CSMs permanently enabled. Such computers could not boot in the normal EFI way, and they'd look just like regular BIOS-based computers. I don't know how common this practice was, though, and in fact I've never verified that the claim is true -- it could be an urban legend. Such a setup is certainly theoretically possible, whether or not such a firmware has ever actually been written.

Neither approach would explain your problem, which seems to be better described as a badly broken EFI.