It doesn't seem to find grubx64.efi under certain conditions.

[jc-lab]

• PC Model : DELL Latitude 3510

I replaced /EFI/Microsoft/bootmgfw.efi with shimx64.efi. And Here have grubx64.efi in the same location.

However, I have seen a screen like the one below.

Failed to open \EFI\Microsoft\Boot\S - Invalid Parameter
Failed to load image \EFI\Microsoft\Boot\S: Invalid Parameter
start_image() returned Invalid Parameter

Is there any character limit, etc.?
I also don't know why the 'S' goes into the path shim looking for.

[miray-tf]

My guess is that shim uses some information of the LoadOptions.
Parsing for that information is done in set_second_stage() in shim.c in the source.

You might get some more information from shim if you manage to boot a linux system on that laptop and enable shim verbose move with
mokutil --set-verbosity true

The BOOTXXXX EFI vafiables might also provide some information.

[jc-lab]

I already ran it with verbose, but didn't find anything else.

Here is the modified code to print a few:
https://gist.github.com/jc-lab/dfeec0765bff8af97da51243a6a73efe

li->LoadOptions doesn't seem to be normal.
Is the laptop firmware the problem?

[miray-tf]

It could be a problem with the firmware or could be that Windows has set some boot options.

You seem to be able to recompile shim for testing, so you could try to use the dhexdumpat() function create a hex dump of the LoadOptions.

By the way, in the output from line shim.c:1585 you get the 'start = S' output. That seems to be where the 'S' filename in the load path comes from.

[lcp]

Maybe we can also check the output of "efibootmgr -v" to see if the Microsoft boot option contains any extra data.

[Metabolix]

Windows bcdedit.exe seems to always put "WINDOWS\0" (in 8-bit chars) in the beginning of the optional data, followed by some other MS-specific stuff. It causes shim error "Failed to open \EFI\mypath\䥗䑎坏S - Invalid Parameter". Maybe the easiest fix would be to check for "WINDOWS\0" specifically.

[BogdanAriton]

Windows bcdedit.exe seems to always put "WINDOWS\0" (in 8-bit chars) in the beginning of the optional data, followed by some other MS-specific stuff. It causes shim error "Failed to open \EFI\mypath\䥗䑎坏S - Invalid Parameter". Maybe the easiest fix would be to check for "WINDOWS\0" specifically.

When I reproduced this problem the text was a bit different: "S xBCDOBJECT={9dea862c-5cdd-4e70-acc1-f32b344d4795}". Because things can differ I thought that the best way would be to verify the input and check if this would qualify for a loader (by checking the path) (36adff8)

[Metabolix]

When I reproduced this problem the text was a bit different: "S xBCDOBJECT={9dea862c-5cdd-4e70-acc1-f32b344d4795}".

The exact visible output may depend on the firmware, whether it has support for CJK characters (fully, partially or not at all) and what data exactly follows the "WINDOWS\0" string. This is not relevant to my solution.

I think your idea of checking the path is good in principle but problematic. When the file doesn't exist (or you get some of the various other errors from EFI_FILE_PROTOCOL.Open()), you now simply assume that the path is bad. How do you know that? What if the file is just missing and the user needs to know that? Also, why would the user have bad data in the first place, unless they are using a known bad tool like bcdedit.exe?

[BogdanAriton]

When I reproduced this problem the text was a bit different: "S xBCDOBJECT={9dea862c-5cdd-4e70-acc1-f32b344d4795}".

The exact visible output may depend on the firmware, whether it has support for CJK characters (fully, partially or not at all) and what data exactly follows the "WINDOWS\0" string. This is not relevant to my solution.

I don't understand where "WINDOWS\0" would be found. I'm trying to get the same things on my side, but I don't.

I think your idea of checking the path is good in principle but problematic. When the file doesn't exist (or you get some of the various other errors from EFI_FILE_PROTOCOL.Open()), you now simply assume that the path is bad. How do you know that? What if the file is just missing and the user needs to know that? Also, why would the user have bad data in the first place, unless they are using a known bad tool like bcdedit.exe?

I agree, I make the assumption that the path is bad, in the examples you have mentioned, I may be wrong here, but all that the load-options is doing is trying to load a second stage or the default and this has to be a path.

[vathpela]

I don't understand what workflow this would be enabling... why are you swapping out bootloaders instead of creating correct boot entries for the OS you're using?

[jclab-joseph]

@vathpela I don't know the exact reason, but there was a problem where the boot order was not actually applied when changing the boot order in efibootmgr on certain PCs.
So I replaced bootmgfw.efi as a trick.

[Metabolix]

@vathpela If you consider #621 which explains the problem in other words, this affects boot entries created in Windows with bcdedit, even when you create an entry for your custom boot loader and try to remove all bcdedit extra options from the entry. The extra data (especially the guid) in the entry seems to be how bcdedit binds entries into the bcd database.

Also #626 contains a similar problem, although the actual tooling and entry contents remain unclear from the report.

Locked boot order is another thing. It should be possible to change it manually in firmware setup. If not, then that's a very sad for OSS in general. In my project some people have reported they can't change the order or that a new entry is not even visible in firmware setup. Who knows. Maybe it would be good to be prepared for this.