Ubuntu 26.10 Secure Boot Changes and /boot Layout Checks

Ubuntu 26.10 reduces the features included in signed GRUB for Secure Boot. Compatibility depends on how GRUB reads boot files, rather than simply which filesystem your root partition uses. Check the filesystem and underlying storage layers containing /boot before upgrading a customized installation.

Canonical confirmed the changes in its October 6 security overview . Earlier descriptions of them as a proposal no longer describe the current status.

Affected Layouts

These restrictions concern the boot path. Btrfs, ZFS, LVM, LUKS and RAID remain available after boot. An encrypted root filesystem and encrypted /boot are different cases. Full GRUB functionality remains available with Secure Boot disabled, but changing security settings requires evaluating the whole boot and encryption configuration. Official changes .

Step 1 Check Secure Boot

The following command reads status without changing configuration:

mokutil --sb-state

SecureBoot enabled means it is active. If the tool is unavailable, inspect UEFI settings first. If EFI variables are unsupported, confirm whether the machine booted in UEFI mode; an error does not establish that Secure Boot is disabled.

Step 2 Locate the Filesystem Containing /boot

findmnt --target /boot --output TARGET,SOURCE,FSTYPE,OPTIONS
lsblk --output NAME,TYPE,FSTYPE,MOUNTPOINTS

Even without a separate /boot partition, findmnt returns the filesystem containing that directory, usually the root filesystem. Do not skip the check just because lsblk does not show a separate /boot mount.

An ordinary ext4 partition might produce:

TARGET SOURCE         FSTYPE OPTIONS
/boot  /dev/nvme0n1p2  ext4   rw,relatime

If FSTYPE is Btrfs, XFS or ZFS, consult the table above. If it is ext4 but SOURCE points to /dev/mapper/... or /dev/md..., inspect the storage hierarchy in lsblk: support for ext4 does not establish support for underlying LVM, encryption or RAID layers. Software RAID also requires checking its level.

A FAT EFI system partition at /boot/efi does not establish compatibility for the filesystem containing the kernel and initramfs at /boot. These commands provide an initial inspection; unusual boot chains require reviewing the actual configuration.

Step 3 Decide When to Upgrade

• Secure Boot enabled with an incompatible /boot layout: keep 26.04 LTS while preparing a backup and migration plan.
• Supported filesystem on an ordinary partition: this inspection finds no restriction described here, but check drivers and other compatibility issues.
• Secure Boot disabled: these reductions do not apply to the current full GRUB path. Repeat the checks before enabling Secure Boot later.

Moving /boot involves partitions, mounts, initramfs and boot configuration. A universal command cannot safely cover all machines. Complete the backup checklist, record storage layout and prepare bootable recovery media first.

For TPM-based unlocking, prepare the recovery key before changing firmware or boot settings. See the hardware-backed encryption explanation  for the relationship between boot state and disk unlocking.

Common Questions

Does an Encrypted Root Filesystem Always Prevent an Upgrade?

No. Check whether the files GRUB must read are behind encryption. An ordinary separate ext4 /boot can follow a different storage path from an encrypted root filesystem.

Is RAID1 Always Compatible?

The official changes retain a RAID1 exception, but you must still check the filesystem and any nested storage layers.

Can a Different GRUB Theme Restore Filesystem Support?

No. Themes and backgrounds do not change signed GRUB’s compiled features. Do not resolve compatibility by bypassing verification or arbitrarily replacing boot components.

Further reading: early official design discussion , 26.10 downloads and upgrade advice.