On 20th August 2024, Windows released a software patch that revoked shims older than 15.8. The shim is an upstream component consumed by multiple Linux distros, including Ubuntu.
Which Ubuntu users are affected
Any user intending to install any version of Ubuntu on hardware that currently runs Windows, with secure boot enabled, and the relevant update installed.
Existing dual-boot setups of any Ubuntu release except for 24.04 LTS, alongside Windows, that has secure boot enabled and has received the relevant Windows update.
Dedicated Ubuntu machines are unaffected.
How this affects Ubuntu users
As a result of this update, any Ubuntu released media that uses a shim older than 15.8 can no longer be directly installed on machines that have applied this Windows update without disabling secure boot first in the BIOS. This may include fresh systems that have had Windows pre-installed or existing dual-boot Windows and Ubuntu systems older than Ubuntu 24.04 LTS.
Whilst Ubuntu 24.04 LTS already includes the 15.8 shim when installed, the current release ISOs use shim 15.7 to perform the installation. Therefore, users will still require updated installation media to resolve this issue for fresh installs of 24.04 on machines that have received the Windows update.
When can you expect a fix?
Mitigating the impact of this change requires shipping Ubuntu releases with updated shim 15.8. This effort is underway, and Canonical will make available updated install media (ISOs) for Ubuntu 24.04 LTS (Noble Numbat) as part of the .1 release on August 29th. The upcoming Ubuntu 22.04.5 LTS release will also include the same updates.
This will ensure that both Ubuntu 24.04 LTS and 22.04 LTS will be installable on systems affected by the Windows update.
How to mitigate this change on existing Ubuntu installations
For existing Ubuntu installations that are experiencing issues it is possible to use the following workarounds before we release the new ISOs:
Ubuntu 20.04 LTS and above:
Disable secure boot in the device BIOS settings.
[optional] Install the system, if you donât yet have an install.
Boot into Ubuntu and then, depending on release version:
24.04: You are good to go, the installed system is fine as the installed system has the 15.8 shim.
20.04/22.04: Prior to August 29th the patch is available in the proposed pocket. After August 29th the patch will become generally available and users will simply need to update their system to upgrade to the new shim using the following command: sudo apt update && sudo apt upgrade shim-signed.
Boot Ubuntu a second time (with secure boot still disabled), this will cause the shim to reset the SBAT.
While we are waiting for the updated Ubuntu 22.04 ISO, I would like to share these steps (deduced from the mentioned workarounds) which may work without the need to disable Secure Boot if we want to install Ubuntu after the mentioned Windows update:
Inside (you may need to extract data.tar if it is not extracted automatically), go to data/usr/lib/shim, get shimx64.efi.signed.latest and copy it in the EFI/boot folder of a Ubuntu USB drive (prepared e.g. using Rufus and ubuntu-22.04.4-desktop-amd64.iso) as bootx64.efi (replace existing one). Similarly, replace mmx64.efi.
This modified USB drive should now be able to install Ubuntu (note there might be a 1-2 min long black screen at bootâŚ).
For an existing Ubuntu installation or after the above fresh installation, the bootx64.efi and mmx64.efi files that normally appear in /boot/efi/EFI/BOOT need to be updated:
We can boot from the modified temporary USB drive I suggest above and choose âTry Ubuntuâ instead of âInstall Ubuntuâ to modify the existing installation on the internal disk.
To determine what is the EFI System Partition (ESP) of the internal disk, try sudo gparted, select your internal disk and find what is the partition that has boot, esp flags, typically /dev/nvme0n1p1 or /dev/sda1 (its size is usually around 100-500 MB).
Then, assuming you downloaded and extracted shim-signed_1.51.4+15.8-0ubuntu1_amd64.deb (and extracted its data folder inside) in ~/Downloads and the ESP is /dev/nvme0n1p1:
You should be then able to reboot to your existing Ubuntu installation on the internal disk.
It might not be necessary after the steps I proposed, but after rebooting to the Ubuntu installation on the internal disk,
means we should go to Software & Updates app, check Developer Options\Pre-released updates (jammy-proposed), close and choose Reload, then in the terminal run sudo apt install shim-signed, then un-check Developer Options\Pre-released updates (jammy-proposed) in Software & Updates to reset the modified settings back to defaultâŚ
Also, if the existing Windows was not starting and you do not have another computer to be able to follow the steps above, try choosing âWindows Boot Managerâ in the UEFI Boot Menu Override (at computer startup try pressing repeatedly F12, F11, F10, F8 or ESC or check section 3 on https://q4os.org/dqa014.htmlâŚ).
Sorry, I realize that after installing Ubuntu, for some reason the updated USB drive does not boot any more, while I still need to update also the bootx64.efi file of the newly installed Ubuntu⌠To be checked⌠Updates of my attempts: updating also mmx64.efi or possibly avoiding to enable â3rd party driversâ during Ubuntu installation seem to help, I am currently checking more in detailsâŚ
I updated my post above with some corrections, it works for me with VMware Windows 11 virtual machines, which do not seem to have an obvious option to enable/disable Secure Boot in their UEFI (and it seems enabled by default since I got the errors related to SBATâŚ).
Note also I somehow âbrickedâ one of my virtual machines by trying to blindly find a way to disable Secure Boot by deleting all âDBâ listed in the UEFI, it seems no OS was accepted any more in its Boot Manager and the Secure Boot-related options disappeared from the UEFI (if I remember well)⌠I could restore a backup of its .nvram file to solve that, but I guess it might not be possible on some real PCs with the same type of UEFI with few options.
At the university I work at, we install Ubuntu LTS alongside Windows on student laptops as part of the programme introduction for CS and AI students. This year, the introduction is planned for August 28th (i.e. one day before the point release is released ), so we expect this issue to impact us.
The mitigation described in your message is of course a potential solution, but does make the install more complicated, especially since UEFI setups do not have a standardized layout and manufacturers often have strange constraints around disabling secure boot (requiring an administrator password, requiring you to enter a confirmation code, et cetera).
We are currently planning on instead installing the latest daily build of the 24.04.1 point release, as available on cdimage.ubuntu.com - this build already ships with an updated shim version, and as we are only a day out from the release of 24.04.1, I would expect this to cause essentially no issues, while sidestepping the complication of disabling secure boot, performing the install, and then re-enabling it.
Are there any issues we should expect from this alternative mitigation?
That is indeed unfortunate timing! 24.04.1 wraps up updates that users who have already installed Noble will have received in the period since launch so we have confidence that as long as the install is successful your experience should be fine. In addition, the blockers that need to be resolved before .1 is released are primarily related to upgrades from earlier releases rather than fresh installs, see Noble Numbat (24.04.1 LTS) Point-Release Status Tracking
With that in mind it may be that your proposal will work for your use-case, however I must provide the usual disclaimers around the fact that we would not officially recommend or support a release that is not available on releases.ubuntu.com and there is always the chance that last minute issues will arise from testing candidate builds.
FYI, I just tried installing the daily build of 24.04.1, and while the USB boots, when I attempt to boot the drive with it installed, I get the same sbat error. So it looks like the packages it installs isnât the same ones itâs booting on the USB?
I just tried to replicate this on a fresh system (only ever had Windows installed on it, has the SBAT error when booting the 24.04 ISO) and canât replicate it; the daily build ISO ships with shim-signed 1.58, installs that, and the subsequent install boots up fine. If it wasnât a fresh install, perhaps the shim youâre booting isnât the one installed by Ubuntu, or is an older version? ÂŻ\_(ă)_/ÂŻ
That said, even if this doesnât work for all machines, we can still fall back on the workaround specified in the OP.
No, mokutil --set-sbat-policy delete is a oneshot command, it deletes the SBAT policy at the next boot; a following boot will then install the default Ubuntu SBAT policy
OK, Iâm trying to get the rationale behind this. If I understand correctly, MS has created a new UEFI variable that new shims are checking to see if theyâre authorised to execute, so itâs up to the potentially vulnerable software to decide of its own execution. Am I good here ?
I encountered this problem late at night on my dual boot Dell XPS13 and am very grateful for the mitigation you presented here. Thank you. This recovered my situation but I think I was the victim of some unlikely circumstances in that I made the Windows update while still running 22.04 LTS. About a week ago I was invited to upgrade to 24.04 LTS but declined temporarily in order to back up my 22.04 data. Having completed the backup I received no further invitations to upgrade to 24.04 LTS and so carried on with 22.04. As I understand it the subsequent Windows update caused the problem. My question, while slightly off topic is why did I not receive any further invitations to upgrade Ubuntu?
), so we expect this issue to impact us.