Align fallback behavior to grub across various methods (also, issues with Dell/Wyse 5070)

[christoph-at-unicon]

There are issues with a particular computer (Dell/Wyse 5070), and it seems this one and shim 15.8 don't go together well. In short, booting this machine via USB is a bit ugly, while via PXE no longer possible at all.

Scenario: Booting the computer via PXE, chain is the usual shim -> grub -> Linux kernel. Up to and including shim 15.7, this just worked. Using shim 15.8 however produces:

Fetching Netboot Image grub/revocations.efi
Fetching Netboot Image grub/<?>Onboard
Unable to fetch TFTP image: TFTP Error
start_image() return TFTP Error

(Where <?> is the Unicode replacement character, and the rest is from the selected boot menu entry "Onboard NIC (IPv4)".)

Then the machine offers various Fx keypresses as an option where to go to but is otherwise stuck.

If anyone really wants me to, I can bisect to identify the change. I reckon it's a23e2f0 ("netboot read_image() should not hardcode DEFAULT_LOADER") which actually is the right thing.

In comparison however, booting using a USB flash drive works, at least it's good enough: There is a similar message about a missing file:

Failed to open \EFI\BOOT\<x>: Invalid parameter

(where is some block character)

... but then shim downloads grubx64.efi as a fallback, and things continue as expected. Also, this behaviour is not new, it's just nobody has noticed so far.

Booting from the internal flash works fine.

This raises two questions:

First, why does the shim try to load these files?

From what I can tell from the dump generated at load-options.c:183, shim sees four additional octets after the "End Entire Device Path" (0x7f 0xff 0x04 0x00) sequence in the option blob, hence does not consider this a valid EFI_LOAD_OPTION. The fallback to split_load_options doesn't to the right thing either. Very blurry photos available upon request - is there a way to redirect shim's debug output to the serial console?

Perhaps shim could work around this situation as this parameter passing seems to be fragile anyway, the comments in parse_load_options were, er, enlightening. But I'll try to take this to the vendor first.

The other question: Why is there a different behaviour across the boot methods?

Answer: For USB, the error code is EFI_INVALID_PARAMETER which leads to the fallback in shim.c:1262. For TFTP however, it's EFI_TFTP_ERROR - which does not. In other words, this simple patch

--- a/shim.c
+++ b/shim.c
@@ -1260,7 +1260,8 @@ EFI_STATUS init_grub(EFI_HANDLE image_handle)
        // If the filename is invalid, or the file does not exist,
        // just fallback to the default loader.
        if (!use_fb && (efi_status == EFI_INVALID_PARAMETER ||
-                       efi_status == EFI_NOT_FOUND)) {
+                       efi_status == EFI_NOT_FOUND ||
+                       efi_status == EFI_TFTP_ERROR)) {
                console_print(
                        L"start_image() returned %r, falling back to default loader\n",
                        efi_status);

aligns the behaviour and restores an acceptable behaviour in PXE boot. Does this make sense?

Related, in HTTP boot no load options are transmitted as far as I can see - therefore I cannot tell whether the above patch needs an extension for HTTP boot.

Unrelated:

-	 * Description=L"" + 0x7fff0400 (EndEntrireDevicePath), it can't
+	 * Description=L"" + 0x7fff0400 (EndEntireDevicePath), it can't

[christoph-at-unicon]

Okay, this is obviously a duplicate of #649

[christoph-at-unicon]

Closing as duplicate.