Comment 2 for bug 1366546

Revision history for this message
Benjamin Tegge (livewirebt) wrote :

Thank you for your reply. I tested a Toshiba Satellite NB10-A-10N as a user reported having trouble with a device of that model series (NB10t-A-101, the "t" in the NB10-A series seems to indicate touch capability). I just looked into the UEFI Specification Version 2.4 (Errata B) and found "3.4.1.1 Removable Media Boot Behavior":

> On a removable media device it is not possible for the FilePath to contain a file name, including sub directories. FilePathList[0] is stored in non volatile memory in the platform and cannot possibly be kept in sync with a media that can change at any time. [...]

From my point of view these sentences state: The information which loader to boot from the supported filesystems is stored in the platform (simply speaking, an entry in the NVRAM of the mainboard) and not available when you take out the drive and try to boot it on another computer.

> If FilePathList[0] points to a device that supports the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, then the system firmware will attempt to boot from a removable media FilePathList[0] by adding a default file name in the form \EFI\BOOT\BOOT{machine type short-name}.EFI.

This describes that booting can be done through \EFI\BOOT\BOOT{arch}.EFI. I think we agree on that, I'm just adding it for completeness.

I admit that I haven't read the entire spec, but I do think that there is a misunderstanding here regarding what removable media is or is not and that this section defines a fallback for usecases when information that is only stored in the platform is not available like installing Ubuntu to an external harddrive, which is still possible with UEFI. (This fallback should be deployed with the default Ubuntu installation as it would enable bootable external and internal installations, no matter if a firmware implementation is considered to be broken, crippled or non-standard.)

I have seen many cases over at AskUbuntu that I would consider being occurrences of this issue in retrospect. We would need a tool (or testcase) that users can run to gather further data if a system follows the standard and boots so called NVRAM entries successfully or requires above method to execute a bootloader in UEFI mode that belongs to Ubuntu.