Hi Restarters
Please be aware that Microsoft Firmware needs to be updated on UEFI secure boot PCs before 27-JUN-2026. This is not needed on legacy boot computers I think only EUFI. Windows 11 machines will update automatically however Windows 10 and Linux machines will not. Please see the two YouTube videos bellow for further information:
Kind regards
Alex
0777 389 8806
Thanks for the reminder Alex, I had forgotten all about this and I have over 2 dozen devices to check.
This potentially a big deal for Repair Cafes.
I only noticed this when connecting to Linux via ssh last week. I was told to run “fwupdmgr get-upgrades” - a command which in all my years of using Linux I’d never encountered. (Millions of) Linux users running a DE like Gnome or Plasma will be currently blissfully unaware of this issue - because you only get the notice in a CLI.
But updating may not all be wine and roses. There’s an old Dell Optiplex 3020 here sandboxing our website - and “fwupdmgr refresh” returns: “WARNING: UEFI capsule updates not available or enabled in firmware setup”.
For older desktops -fwupdmgr will fail to update the keys out of the box because “UEFI Capsule Updates” are disabled or poorly supported in the original BIOS. Older BIOS versions lack proper ACPI table support for capsule updates. The Optiplex 3020 dates to 2013.
First - for Boot Mode: Ensure it is set to UEFI, not Legacy. Next - Capsule Updates - look for an option explicitly named “Enable UEFI Capsule Firmware Updates” or “Allow Windows UEFI Updates” - and enable it.
If you can’t find a “Capsule Update” setting in the BIOS, the motherboard BIOS version may be simply too old to support certificate modification via Linux.
The Fail-Safe Option - Disable Secure Boot: If an older motherboard absolutely refuses to accept the new certificate variables via Linux - Disable Secure Boot should completely sidestep this issue. It ensures the computer won’t mysteriously fail to boot after a routine kernel update later this year.
The “New ISO” Boot Failure Scenario:
When Dual-Signing Ends: Right now, Linux distributions should be dual-signing their installation media with both the 2011 and 2023 keys to maintain compatibility. However, once the old 2011 keys fully expire and are blacklisted, newly compiled Linux bootloaders (shim) will only be signed with the Microsoft UEFI CA 2023 certificate.
The Motherboard’s Reaction: When you plug that new ISO into an old, unpatched motherboard, the motherboard’s out-of-date db database will only look for the 2011 signature. Because it cannot find a valid 2011 signature and doesn’t know what a “2023 certificate” is, the firmware will flag the USB as an untrusted boot device.
The Symptom: The person doing the install will see a generic firmware error like “Secure Boot Violation”, “Invalid Signature Detected”, or the USB drive will simply fail to appear as a valid boot option.**
The Bypass: When installing a new Linux distro on older hardware, the fastest workaround is to simply Disable Secure Boot before booting the USB installer. This completely turns off signature checking and allows the new ISO to boot instantly. Being mindful of this will avoid much weeping and gnashing of teeth - and hair pulling by Repair Cafe volunteers. Hope I got all this right.
Thanks Len.
Monique, can this be more widely publicised from the Restart Project?
Kind regards
Alex
I read that Asus motherboards will reset secure boot to On when a firmware update is applied, so always check after doing that.
Best to ask @neil about that.
Have been trying to get some idea about how soon new Linux ISOs are likely to be affected - but without much luck. Some indications are a timeline of at least 3 to 5 years. Other’s are saying the shims signed with the 2011 keys may be deprecated quite quickly. All I can suggest is to wait until Ubuntu releases 26.10 in October - and see what happens.
Existing Linux installs should not be in any way affected - but there’s always the hypothetical - that if there’s another nasty malware like Black Lotus UEFI bootkit - then that might trip a shim rewrite - with only the 2023 security keys - and so when that update’s applied …
I feel like that guy out of Dad’s Army saying “Don’t panic”.
Cheers - Len
Thanks all, and thanks @Len for the research!
Regarding publicising it more widely, my reading is that this is something that it’s most useful for repairers at repair groups to be aware of, right? The possibility of mismatched certificates on a laptop/distro combo they are working with. It’s less something to share to the wider public, particularly if Win 11 is unaffected and Win 10 updates automatically. (And Linux users will perhaps have the resources to investigate it themselves.) Right?
e.g. It’s something we could share with other networks of repair groups that we are friends with, for them to pass on to their own repair groups, less so us putting out social media posts targeted to the general public.
Just seen this, our first LRC is due to run this coming Saturday. Started watching the two referenced videos, however, I have a very specific question.
I’ve just downloaded the LRC Cinnamon Mint 22.3 ISO (June 9th Version). How is this impacted? I’ve upgraded three laptops with it and everything has gone well. As Saturday is 27th this could be a problem, correct?
In reality I do not expect to do any migrations this week, however better be prepared than not.
I just had a re-read of @Alex_Horn post and realised it applies only to UEFI devices, so that’s a first qualifier to check for, needs adding to my process list.
I’m about half way through checking a dozen Mint laptops dated from 2011, most are about 7 to 10 years old, I’ve not had any newer motherboards to contend with.
This has been my workflow:
If I can’t get into BIOS or the BIOS settings are unclear, I boot as normal and in a terminal type the command…
sudo mokutil --sb-state
… the result will either give the name of the installed cert/s or it will print words to the effect that UEFI is not supported or is disabled. So far I’ve been able to boot off disk on all devices but if for any reason you can’t, then boot off USB.
Most of my devices (so far) have no UEFI or have secure boot disabled. On those with secure boot I’m disabling it as I’ve not found updated certs available for them.
If you want to leave secure boot enabled and the cert is 2011, then try…
sudo apt update && sudo apt upgrade shim-signed
… after that you can use …
sbverify --list /boot/efi/EFI/ubuntu/shimx64.efi
… to check if the cert was updated by any of the Mint updates. If not then you’ll need to see if the hardware vendor has provided an update.
If anyone has info to impart that improves my steps please do share.
To be more specific…
with ASUS mainboards, SB comes back on when using “Load Optimized Defaults” in the bios or when updating the bios.
Please see the attached PDF file for the Linux commands I used to update the firmware on my work laptop.
Kind regards
Alex
Hi Robin
Mint should be OK for some time on old hardware. Though it would be a really good idea to start turning off secure boot now when installing any Linux on older computers.
From what I can find - Mint 22.3 is using the dual signed shim from Ubuntu 24.04 that’s OK with the old certificates. Mint 23 is due in December and is supposed to use the dual signed shim from Ubuntu 26.04 - but I can’t find solid confirmation of that. Keep your copy of 22.3 handy just in case.
Current installs have some protection from future updates and upgrades - because there’s now a utility called sbchooser (part of the efivar bundle). It’s the result of a collaboration between Ubuntu and Red Hat. This should be included with Mint and other distros. What it’s supposed to do is scan the NVRAM when updating or upgrading - and if it only finds the 2011 certificates - it makes sure the old compatible shim is retained.
There’s this explanation of sbchooser here - though I wouldn’t recommend anyone read it.
It scans NVRAM trust databases and ranks a list of candidate bootloader files from “most preferred” to “untrusted”. It then evaluates and sorts bootloaders using a strict priority ladder:
It first prefers any binary whose exact cryptographic hash is directly whitelisted inside the motherboard’s db.
It then evaluates binaries signed by certificates chaining to your db. It scores them based on mathematical security strength (e.g. favoring modern 256-bit signatures over older, weaker ones).
If multiple bootloaders have equal cryptographic trust, it uses a last-resort calculation to prefer the binary with the latest expiration date in its certificate chain.
Hope everyone is putting up with the heat OK.
Cheers - Len