REVOKED UEFI BOOTLOADER detected by rescuezilla-2.5.1-64bit.noble.iso detected by RUFUS-4.6

[Anonymous]

I am trying to put the latest Rescuezilla iso on a PNY 256 GB new USB stick. I first burned it on Linux Mint using its built-in Image Writer App. This ran and loaded but failed because a device was supposedly busy.

Then I decided to try to burn the USB with Rufus on Win 10 . RUFUS rejected the ISO because it has a revoked UEFI bootloader. I downloaded the ISO from the Rescuezilla home page so I assume it was reputable. And the checksums checked out.

I hope someone can shed some light.

[Daisuke Daisn]

I posted the above BUG REPORT but I was not signed in. So this reply will hopefully allow any helpful posts to be drawn to my attention. Thank you.

[Anonymous]

I was able to get Rufus to write the ISO but then it would not run. I am not able to turn off secure boot on my mobo which is an ASUS WS C422 PRO/SE LGA2066 ECC DDR4 M.2 U.2 ATX Motherboard for Intel Xeon W-Series Processors.

[Rescuezilla]

From: https://github.com/rescuezilla/rescuezilla/issues/525#issuecomment-2519451103

Thanks for raising this issue. This will require a new version of Rescuezilla to fix.

This article What the fuck is an SBAT and why does everyone suddenly care provides a detailed technical explanation of what appears to be the root cause here.

Rescuezilla is built upon the Ubuntu Linux distribution using the Linux kernel and signed bootloader packages it provides, there's been changes in how these are validated for UEFI Secure Boot known as SBAT.

By building a new release (certainly for the new Ubuntu 24.10 Oracular) it will pull in the bootloader packages with this new SBAT level and that should solve the issue.

That said, looking at the 'Ubuntu Changelog' link on the secure boot package [1], I can see an update for Ubuntu 23.10 (Mantic) but one not the older Ubuntu 24.04 (Noble) which is a long-term support release so should also be getting updates.

[1] https://packages.ubuntu.com/noble/shim-signed

[Daisuke Daisn]

Thank you for calling this earlier bug report to my attention. I guess the question is when will a version of Rescuezilla be released which does not have this issue. And in a pinch, which is the most recent Rescuezilla release that does not have this issue, assuming older versions did work properly.

[Rescuezilla]

I'll try and get a new release out by next week.

Other versions of Rescuezilla v2.5.1 and earlier all use the same boot files from the build environment, so will all suffer the issue. I believe pulling the new build files from an upgraded build environment (which I've done but haven't tested heavily) should sort it out for all releases, including older ones -- but I'll confirm.