"Invalid image" error #490
Comments
|
It seems like there is something wrong with loader_options. After resetting the BIOS, it works fine. Could this be considered a shim potential bug? |
|
People have the same issue on selected laptops with Fedora's shim v15.6-1 when Secure Boot is disabled. |
|
Shim v15.6-1 Fails to boot on ASUS B85M-E motherboard with Nightly Fedora Rawhide ISO.
|
|
reporting in with another B85M-E that cant boot with this shim. Have someone in my discord who also has the same board and also reported the same issue. Fedora 36's ISO still uses 15.4, 15.6 is only provided via updates. I made a new custom fedora 36 image and added the shim package to the excludes list in the updates repo -- and sure enough it booted using the 15.4 shim packages from the original fedora (non-updates) repo. |
|
First thing to check would be whether Asus has a firmware update available for that motherboard compared to what it's shipping with (and if so, whether applying it resolves the issue). I do have a different Asus motherboard, but it both has no issues with the newer shim and has been updated. I'd also be curious what the EFI boot entries are, both according to the firmware and according to |
The bios is completely up to date, that was the first thing I checked. Also it's not just this specific asus board. I have another user that reported the same issue on an older Dell: And as noted reverting the shim to the older 15.4 version in my ISO fixed the issue for him as well. I'll grab the efibootmgr -v output shortly and report back. |
|
|
@GloriousEggroll, since you already have the hardware, could you try to debug the issue? The bug happens somewhere here, but since this function haven't been changed between 15.4 and 15.6, I won't be surprised if there's something with gnu-efi instead. |
sorry but I wouldnt even know where to begin on debugging this. I can build an rpm and make a bootable iso with it but thats about the extent of what i know in regards to how this shim works much less how to debug it |
|
@GloriousEggroll, shim, stored in (EFI)/efi/boot/bootx64.efi, tries to boot (efi)/efi/boot/grubx64.efi, and fails to do so because, for some reason, the internal functions cut off the file name and try to boot (efi)/efi/boot (the directory). You run The functions of interest are load-options.c/generate_path_from_image_path and shim.c/load_image. |
In 6c8d08c ("shim: Ignore UEFI LoadOptions that are just NUL characters."), a check was added to discard load options that are entirely NUL. We now see some firmwares that start LoadOptions with a NUL, and then follow it with garbage (path to directory containing loaders). Widen the check to just discard anything that starts with a NUL. Resolves: rhboot#490 Related: rhboot#95 See-also: https://bugzilla.redhat.com/show_bug.cgi?id=2113005 Signed-off-by: Robbie Harwood <rharwood@redhat.com>
|
If someone is able to test #505, it would be helpful to know if that resolves the issue. |
In 6c8d08c ("shim: Ignore UEFI LoadOptions that are just NUL characters."), a check was added to discard load options that are entirely NUL. We now see some firmwares that start LoadOptions with a NUL, and then follow it with garbage (path to directory containing loaders). Widen the check to just discard anything that starts with a NUL. Resolves: rhboot#490 Related: rhboot#95 See-also: https://bugzilla.redhat.com/show_bug.cgi?id=2113005 Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Is it possible to provide the build in a form of .efi file, so @GloriousEggroll and @Silexium could test the patch? |
|
I was able to build the unsigned shim rpms patched with #505 and also the shim rpms based off them, can confirm this resolves the issue on the ASUS B85M-E. Thanks for the fix @frozencemetery. @ValdikSS I've set up a copr repo if you need it for testing: https://copr.fedorainfracloud.org/coprs/gloriouseggroll/shim-test/ |
In 6c8d08c ("shim: Ignore UEFI LoadOptions that are just NUL characters."), a check was added to discard load options that are entirely NUL. We now see some firmwares that start LoadOptions with a NUL, and then follow it with garbage (path to directory containing loaders). Widen the check to just discard anything that starts with a NUL. Resolves: #490 Related: #95 See-also: https://bugzilla.redhat.com/show_bug.cgi?id=2113005 Signed-off-by: Robbie Harwood <rharwood@redhat.com>
|
Thanks for the testing. For those hitting this issue before their distros update the officially signed shim: in my opinion, it is better from a security perspective to run the older, signed shim rather than disabling secureboot to run the patched, unsigned shim above from #505. (If you're able to enroll your own keys, of course you can have the best of both worlds; and if you're just testing fixes, none of this applies anyway.) |
|
This problem does not occur if I use Ventoy to load the ISO, with Fedora Media Writer and GNOME Disk Utility I get this problem. The topic is already closed, but I wanted to leave a comment. |
In 6c8d08c ("shim: Ignore UEFI LoadOptions that are just NUL characters."), a check was added to discard load options that are entirely NUL. We now see some firmwares that start LoadOptions with a NUL, and then follow it with garbage (path to directory containing loaders). Widen the check to just discard anything that starts with a NUL. Resolves: rhboot#490 Related: rhboot#95 See-also: https://bugzilla.redhat.com/show_bug.cgi?id=2113005 Signed-off-by: Robbie Harwood <rharwood@redhat.com>
There is a signed grubx64.efi , but it fails to boot.
What should I check?
Full Log:
The text was updated successfully, but these errors were encountered: