If you suddenly find your system booting an older kernel, even though you know a new one’s available, and you’ve even used clr-boot-manager to select it explicitly, there’s a chance you’ve run into a very specific failure scenario.
- Clear Linux uses UEFI to boot.
- UEFI looks for an EFI Service Partition (ESP) on your hard drive to load the bootloader and kernel from
- The ESP is usually VFAT-formatted
- We keep the partition unmounted after boot because it’s easy to corrupt
- Our tools (e.g.
clr-boot-manager) that need to modify the contents of the ESP mount it on demand
- We call
boot.mountto mount the ESP
boot.mountis provided by systemd-gpt-auto-generator
Where things go wrong
boot.mount without issue. Sometimes it doesn’t, though. The most common failure case is when something has placed files in the
/boot directory on your root device.
/efi/) mount point is non-empty, no mount units are generated…
boot.mount does not exist, and clr-boot-manager cannot mount the ESP to write the new kernel and/or bootloader configuration, but still writes the changes to the
When this happens, you’ll see one set of contents (that looks correct) in
/boot, but it’s actually just the directory on your root device. Meanwhile, at boot, UEFI still uses the (untouched) ESP.
Diagnosing the issue
First, check whether anything is actually mounted on /boot
$ mountpoint /boot /boot is not a mountpoint
/boot is not a mountpoint and you have files there, then
boot.mount will not be auto-generated, and you will have problems.
/boot is mounted, try unmounting it and check again:
$ sudo umount /boot $ mountpoint /boot /boot is not a mountpoint $ ls -la /boot
If you still have contents in
/boot, then you will run into this issue.
Copy the contents of /boot to another directory just in case. You shouldn’t need these later, but at least you can restore with a boot disk.
Find the device corresponding to your ESP and mount it manually:
$ lsblk -o NAME,PARTLABEL NAME PARTLABEL sda ├─sda1 EFI ├─sda2 linux-swap └─sda3 /
In this example,
sda1 is the ESP (partlabel EFI), so:
$ sudo mount /dev/sda1 /boot
Now you should see the expected files. clr-boot-manager should be able to update from here, so run:
$ sudo clr-boot-manager update
/boot looks like you expect, then reboot.