-
Notifications
You must be signed in to change notification settings - Fork 291
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
It doesn't seem to find grubx64.efi under certain conditions. #370
Comments
My guess is that shim uses some information of the LoadOptions. 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 The BOOTXXXX EFI vafiables might also provide some information. |
I already ran it with verbose, but didn't find anything else. Here is the modified code to print a few:
|
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. |
Maybe we can also check the output of "efibootmgr -v" to see if the Microsoft boot option contains any extra data. |
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. |
Windows bcdedit.exe creates boot entries where load options begin with "WINDOWS\0" (in 8-bit chars), followed by some Windows-specific data which is useless for shim. This data causes shim error "Failed to open \EFI\mypath\䥗䑎坏S". Resolves: rhboot#370 Signed-off-by: Lauri Kenttä <lauri.kentta@gmail.com>
Windows bcdedit.exe creates boot entries where load options begin with "WINDOWS\0" (in 8-bit chars), followed by some Windows-specific data which is useless for shim. This data causes shim error "Failed to open \EFI\mypath\䥗䑎坏S". Resolves: rhboot#370 Signed-off-by: Lauri Kenttä <lauri.kentta@gmail.com>
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) |
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 |
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 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. |
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? |
@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. |
@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. |
Why is no one fixing this???? |
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.
Is there any character limit, etc.?
I also don't know why the 'S' goes into the path shim looking for.
The text was updated successfully, but these errors were encountered: