Comment 29 for bug 1845289

No; this patch is wrong.

For starters, you really ought to have shim installed, and that is the primary cause for such failures -- somehow your install is incomplete, and shim was removed either because the package was removed, or through the use of boot-repair (IIRC it replaces shim with using grub directly, which is not supported).

Then, the code for the chainloader already is supposed to handle Secure Boot being off -- if it's disabled, the linuxefi_secure_validate() function sees that and returns 1 (image is deemed valid, since SB is disabled). Then we run grub_secureboot_chainloader_boot(), which will execute handle_image(), which should immediately check read_header() and find out, again, whether Secure Boot is enabled and/or if shim is available; returning with whatever status was retrieved reading the header for the binary that is to be chainloaded.

I'd expect that if Secure Boot is not enabled, you would again have a return code of 0 there, and move on to using the normal chainload behavior of load_image and start_image.

Please, if you're running into this issue, try stopping at the grub menu, and edit the chainload entry to add:

set debug="chain"

At the top, taking a screenshot or video of the boot process that you can then attach here. We really need to know if this is caused by one unusually built binary, or what precisely is going on before making any patches to GRUB.