If your system has Secure Boot enabled, you may have attempted to boot your Lubuntu installation, only to be presented with a blue screen with a “Security Violation” error on it. This post describes why this is happening, and how to fix it.
The fix
There are two possible fixes here. The easiest one for most users will be to disable Secure Boot temporarily in your system’s BIOS. This should permit your system to boot. Once the system boots, fully update all installed operating systems on your computer. When finished, you can re-enable Secure Boot and it should continue to work.
If you are unable to disable Secure Boot for some reason, you can update the system from within a live ISO. If your system does not have full disk encryption enabled, this is easy.
Warning: Do not proceed with these steps if full disk encryption is enabled, as this will not work with full disk encryption… If you are using full disk encryption, it is highly recommended that you simply disable Secure Boot, update your system, and then re-enable Secure Boot. We intend to add instructions for how to handle encrypted systems later. If you need help now, you may want someone to walk you through how to fix this problem. You can join the #ubuntu channel on Libera.Chat and ask for help. Please be patient, it can take a while for someone to respond.
Firstly, download the latest Lubuntu 22.04.2 ISO. A 22.04.1 or 22.04 ISO will not work. The latest Lubuntu 22.04.2 ISO can be downloaded here: https://lubuntu.me/downloads/ Once you have downloaded the ISO, flash it to a USB drive using a suitable bootable USB flash drive creator. balenaEtcher works well here.
Once you have a bootable flash drive, boot the affected system from the flash drive. You will soon reach a Lubuntu desktop.
At this point, you will need to mount the partition that you installed Lubuntu to. To do this, open QTerminal, and run lsblk. This will display a list of drives and partitions in your system. You will usually be able to tell which partition you installed Lubuntu to by looking at its size. A list of drive and partition IDs will be displayed alongside, usually with names like “sda2” or “nvme0n1p2”. Identify the Lubuntu partition on your main drive and keep track of its ID.
Once you have determined your Lubuntu partition’s ID, run:
sudo mount /dev/PARTITION_ID /mnt
Replace PARTITION_ID with the ID of your Lubuntu partition. For instance, if your Lubuntu installation is on sda2, you would run:
sudo mount /dev/sda2 /mnt
Once this is done, run the following sequence of commands one at a time (do not simply copy and paste the whole block of commands):
sudo mount --bind /dev /mnt/dev
sudo mount --bind /sys /mnt/sys
sudo mount --bind /proc /mnt/proc
sudo mount --bind /dev/pts /mnt/dev/pts
sudo mv /mnt/etc/resolv.conf /mnt/etc/resolv.conf.bak
sudo cp /etc/resolv.conf /mnt/etc/resolv.conf
sudo chroot /mnt
apt update
apt full-upgrade
exit
sudo rm /mnt/etc/resolv.conf
sudo mv /mnt/etc/resolv.conf.bak /mnt/etc/resolv.conf
reboot
The system will prompt you to remove the flash drive before restarting. Do so, and you should be able to boot Lubuntu again.
Security Violation? What on earth happened here?
This error is nowhere near as scary as it looks - it’s not an indication that something’s gone wrong with your system’s security. In fact it indicates that Secure Boot is working correctly, though sadly something’s gone wrong to make it not want to boot your system anymore.
Recently, Canonical updated their UEFI Secure Boot signing key. This key is used to mark Ubuntu’s bootloaders, kernels, and other critical boot files as “safe to boot”. Essentially, if a boot file is signed using this signing key, and the system has not been otherwise instructed to not boot that file, it will boot it. Files that are not signed with the proper key, and files that are marked as unsafe for some reason, are not booted.
With Canonical updating their Secure Boot signing key, all new official kernels and boot files for Ubuntu are now signed with the new key. In order to keep older files from being booted, an update was also released that modifies a system’s Secure Boot Advanced Targeting (SBAT) variable. This variable is stored in an area of the system’s memory outside of the hard drive, and it essentially acts as a way of determining if a file has been marked unsafe or not. The updated SBAT variable now marks older kernels and boot files (including the bootloader) as unsafe, so that only newer kernels and boot files signed with the new key can be booted.
Usually, this update happens without causing any noticeable effect to the system - the key and SBAT variable are updated without user intervention and everything works. However, in some tricky corner cases, sometimes boot files are left on the system that are still signed with the older key. As the SBAT variable now identifies these files as unsafe, the Secure Boot system refuses to boot them. If one of those files happens to be the bootloader used by Lubuntu, Lubuntu will fail to start.
The solution is to simply replace all of the outdated boot files on the system with newer ones that are signed with the correct key and that are not marked as unsafe. This can be done from within the affected system by disabling Secure Boot, updating the system, and then re-enabling Secure Boot. Or it can be done from a live USB by mounting the partition containing the outdated Lubuntu installation, and then running a system update from there.
I can’t turn off Secure Boot, and I use full disk encryption. Why are the above instructions not sufficient?
In order to update a Lubuntu installation on an encrypted partition, you need to first set up the partition to be accessed, then mount it. Due to how full disk encryption on Ubuntu works, you need to know what name to call the partition when you are setting it up to be accessed. This name can vary depending on your setup. If you get it wrong, your system will probably fail to boot after updating it (though it won’t fail on the Security Violation screen anymore, the failure will happen later in the boot process). We intend on adding the instructions for figuring out the correct name for the partition in the near future.