startup.nsh not executed unless EFI shell is opened

[kpfleming]

I'm guessing this is actually an EDK2 problem, but...

I installed Debian 11 prerelease onto an SSD (using debootstrap), then unpacked version 1.27 of this firmware package into the ESP. I added a startup.nsh file with contents FS0:\EFI\debian\shimaa64.efi so that I would not need to copy anything into FS0:\EFI\boot (because doing that would mean keeping it up to date as new versions of Grub and/or the boot shim are installed).

This works, but only if I press F1 while the raspberry logo is displayed. I don't need to do anything else; after pressing F1 there is a timeout before startup.nsh gets executed, and then it does and the system boots.

If I don't press F1 at the raspberry logo, then booting from the SSD is skipped and the firmware tries the four PXE/HTTP options, then gives up.

[samerhaj]

This is correct. startup.nsh is processed by Shell.efi... not by anything else in the UEFI firmware.

Did you try to make the built-in UEFI Shell the first in the bootlist, thus forcing it to run before the PXE/HTTP options? If the Shell runs by default (equivalent to you pressing F1 during boot), it should find and process the startup.nsh from any ESP file system you put it on.

[kpfleming]

Ahh, that's totally logical, since startup.nsh is in fact a shell script :-)

It appears that 'UEFI Shell' is not a boot option so it is not available in the list of options for controlling the boot order. I could try deleting all of the other boot options, but since I am booting from a USB-attached drive I can't easily persist those changes, so I'll drop this startup.nsh idea for now.

[samerhaj]

I wonder why UEFI Shell is not showing up as a boot option by default.. it certainly used to in older FW.. @sunnywang-arm maybe can take a look?

[sunnywang-arm]

I wonder why UEFI Shell is not showing up as a boot option by default.. it certainly used to in older FW.. @sunnywang-arm maybe can take a look?

@samerhaj @kpfleming Yeah, UEFI Shell is a boot option showing in the boot manager menu (Boot order) by default, but it won't be loaded in default boot (normal boot processing) because its attributes don't have LOAD_OPTION_CATEGORY_BOOT set. In other words, users need to manually load the shell boot option from the boot manager menu or press F1 to load it.

Since there is a use case, I think we can register the shell boot option with LOAD_OPTION_CATEGORY_BOOT set. If anyone has reason to not register the shell boot option with the LOAD_OPTION_CATEGORY_BOOT set, we can have a setup option to enable/disable this. What do you guys think?

By the way, I found something weird that we register the shell boot option with no attribute bit set, and now it is showing on the boot manager menu, which is different from my expectation. I will spare time to take a further look.

  ShellOption = PlatformRegisterFvBootOption (&gUefiShellFileGuid,
                  L"UEFI Shell", 0); 

Tag @pbatard @ardbiesheuvel for also getting their opinion.

[ardbiesheuvel]

The Shell boot option was removed because with fastboot enabled, it will execute without any devices connected, so FS0: etc will not exist in the first place.

[samerhaj]

since we are re-working the fastboot support, and possibly disabling by default, should we reconsider adding the LOAD_OPTION_CATEGORY_BOOT to the Shell, and allowing it to boot by default? Worst case, like what @sunnywang-arm suggested, we can have a Setup option to disable/enable this behavior

[ardbiesheuvel]

since we are re-working the fastboot support, and possibly disabling by default, should we reconsider adding the LOAD_OPTION_CATEGORY_BOOT to the Shell, and allowing it to boot by default? Worst case, like what @sunnywang-arm suggested, we can have a Setup option to disable/enable this behavior

I don't have any problems with that: if you get dropped into the shell inadvertently with the default build and settings, you should see all the devices connected. Only if you enable fastboot explicitly, you could end up in this situation.

[paulwratt]

Did this get implimented? Does it function as expected when startup.nsh is present (and without)?

Can startup.nsh be used to solve the "enable DeviceTree", "preset GPIO" and "no 3Gb limit" issues mentioned elsewhere?