"Enable runtime UEFI media validation" checkbox breaks Ubuntu 26.04 installer

[gottagofaster236]

Checklist

• I have been made aware that if my problem can be summarized as "I've created or tried to create a media using Rufus, and ...", and I am not including a log, this issue will be summarily closed.
• I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
• I performed a search in the issue tracker for similar issues using keywords relevant to my problem, such as the error message I got from the log.
• I clicked the 'Log' button (🗒️) or pressed Ctrl-L in Rufus, or used DebugView, and copy/pasted the log into the section that says <FULL LOG> below.
• The log I am copying is the FULL log, starting with the line Rufus version: x.y.z - I have NOT removed any part of it.

Additionally (if applicable):

• I ran a bad blocks check, by clicking Show advanced format options then Check device for bad blocks, and confirmed that my USB is not defective.
• I also tried one or more of the following:
  • Using a different USB drive.
  • Plugging the USB into a different port.
  • Running Rufus on a different computer.
• If using an image, I clicked on the (✓) button to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.

Issue description

If you enable that checkbox while creating a Ubuntu install media, your EFI/boot will look like this:

bootx64.efi
bootx64_original.efi

because it inserts its own EFI file that first validates the media, and then executes the original EFI.

Then while installing Ubuntu, you'll get a very unhelpful "Something went wrong" screen as the installer tries to show you disk partitions, and then the install won't proceed any further.
If you dig hard enough through logs then you'll see it's caused by:

unexpected multiple matches for installer shim obtained using globbing pattern ".*/cdrom/EFI/boot/boot*.efi"
which was introduced in snapd by this commit (pull request) in June 2025.

This is not an issue if you install Ubuntu without that checkbox checked, as then there's only one bootx64.efi.
I verified that by manually deleting bootx64.efi and then manually renaming bootx64_original.efi into bootx64.efi, after which the install succeeded without any other changes.

[pbatard]

Thanks for the report.

I'd say Ubuntu, rather than Rufus, broke themselves, and it should be fixed on the Ubuntu side.

Ubuntu decided that they don't want to see multiple bootloaders, so if we follow that logic, it doesn't matter how we rename the bootloader, because ultimately, we will always have two bootloaders here one way or another, that Ubuntu can choke on, and I'm not going to start a game of hide and seek with Ubuntu when their logic that attempts to detect the shim is flawed. I don't even see why they would flag this as an error in the first place. So there's more than one EFI/boot/boot\*.efi so what? As long as you do detect one, what is the issue here? What if people decide to create dual boot media for x64 and aarch64 from two Ubuntu ISOs for convenience of installation? Then you're going to have multiple matches too.

The idea that people should use the media as it is and not modify in the slightest it is flawed. A good design should only detect actual error conditions (multiple boot***.efi certainly isn't one, as it prevents neither boot nor does it impair the bootloader's actions) and let everything else slide.

So, at this stage, I don't think I want to do anything in Rufus. Instead, unless you want to do that yourself, I will just log a bug with Ubuntu and wait for them to fix it... or (and this is more or less what I expect) vehemently try to push the wrong idea that their media should be immutable and that nobody should attempt to add extra elements to it, in which case, I guess the Ubuntu installation issue will direct people to use distros that don't try to shoot themselves in the foot.

It may sound disappointing, but I've really grown tired of trying to play nice and add workarounds for distros that do stupid things, like Ubuntu is doing here, so there comes a stage where I have to say enough is enough, and get the distro maintainers to realize that, gasp, people may have valid reason to alter their media (since, well, Open Source is all about giving the user freedom to modify what they get if they aren't entirely happy with it), and therefore that the distro needs to take that into account.

Now, from past interaction with them I do have some hope that the Ubuntu folks will get it. But if they don't, then it's going to be a stalemate, because, again, choking on detecting multiple UEFI bootloaders is a very stupid thing to add to your boot scripts and needs to be removed, not just for Rufus, but for the sake of every single user who is ever going to want to add extra stuff in the EFI/boot/ dir for one reason or another (heck, maybe they got breakage and want to try a fix they want to submit to the Ubuntu folks, so they renamed the org bootloader as bootx64_org.efi... and which the Ubuntu folks will never get if they fight the presence of extra binaries and therefore actively prevent testing that could help them improve their distro).

[gottagofaster236]

unless you want to do that yourself, I will just log a bug with Ubuntu

Please do! (I'm not sure I wanna push this issue further by myself, as I already found a workaround.)
Thanks a lot for your work!

[pbatard]

Okay, I'll do that (when I have a chance). And I'll update this issue when I do.

[pbatard]

It might be worth investigating how the "Enable runtime UEFI media validation" option interacts with the bootloader configuration in the installation process

No.

The issue is explicitly clear, and was properly investigated by @gottagofaster236 to find the root cause. There's absolutely zero need for additional data or investigation at this stage, and there's no such thing about "interacting with the bootloader configuration in the installation process". The bootloaders are chain loaded and the configuration (what bootloader will execute) is defined by the UEFI firmware implementation. Once that has occurred, the installation process doesn't look back, and doesn't care which bootloader was executed when as it should.

The only issue is that (and this is not a configuration or even a pure installation issue) is that the Ubuntu maintainers rather foolishly added a script that looks how many bootloaders matching a specific pattern exists, and stops the installation if it finds more than one.

[pbatard]

As you will have seen, I finally submitted canonical/snapd#17643 to try to address the issue on the Ubuntu side. Unfortunately, the limitations of golang's default globbing, which is quite limited and doesn't accept {abc,def,...} for globbing means this is not the easy one-liner fix I hoped it would be, so we'll have to see how it goes down with the Ubuntu maintainers.

[pbatard]

Well, submitting PRs for the go parts of the custom snapd stuff Ubuntu does is a major PITA, and I already spent way more time than I am comfortable spending, to want to go back and try to fix the unit tests, so I'm not going to bother trying to contribute to snapd further, especially considering that this would have been a 5 minutes job, had Google chosen not to cripple the default globbing engine of the Go language... Wasn't Go supposed to make programming easier?

So I'm just going to defer the issue until either Ubuntu agree that they have an issue on their hand and agree that they want to fix it themselves, or, in one or two years time, I produce a new Secure Boot signed uefi-md5sum bootloader (that'll have to be signed with CA2023 which is why I really don't want to rush into producing one right now because I want uefi-md5sum to continue to work, for non-Ubuntu worflows, and for older machines that haven't been upgraded for CA2023 and may never well be), where, this time, it will literally take me 5 minutes to apply a workaround for the ill-devised "Everything that starts with boot and that ends with .efi has to be a UEFI bootloader and there can only ever be one" that Ubuntu has chosen to go with (UEFI bootloaders are not Highlanders — There can be more than one).