I have an NUC7i7DNHE. The space bar menu (or F1) offers two kernels, Clear-linux-native-5.3.1-838 and Clear-linux-native-5.2.17-836. The 5.3.1-838 kernel hangs.
When I bring up the 5.2.17-836 kernel, all is ok, and it says the OS is updated to version 31150. I run swupd update, swupd diagnose --picky, and swupd repair --picky, all with sudo, they say all is ok. A “uname -a” still says the kernel is 5.2.17-836.
When I restart the server, it tries again to bring up the 5.3.1-838 kernel which still hangs. This also happens when I turn it off and repower it on.
How do I update so the version 31150 kernel comes up and is the default?
You could try sudo clr-boot-manager list-kernels and then sudo clr-boot-manger set-kernel <kernel name> if for some reason you stay stuck on an older kernel.
uname -a is still “5.2.17-836.native”, i.e., the kernel I chose in the menu on boot.
On sudo reboot, the same old menu comes up with the old bad kernel 5.3.1-838 and the still working kernel 5.2.17-846 as options.
It’s as if there’s a hidden boot partition that sudo autoupdate is not updating.
I can’t find any sign of the bad 838 kernel in the /boot dirtree, at all.
Something must be hidden, not in the / filesystem.
The only non-updated files in /boot (all dated Sept. 25) are:
/boot/EFI/org.clearlinux/kernel-org.clearlinux.native.5.2.17-836
/boot/loader/entries/Clear-linux-native-5.2.17-836.conf
/boot/EFI/BOOT/BOOTX64.EFI
sudo bootctl --esp-path=/boot status
lists Current Boot Loader as “systemd-boot 243” going to /EFI/org.clearlinux/bootloaderx64.efi
but /boot/EFI/org.clearlinux/bootloaderx64.efi is updated.
dirtree /usr/lib/systemd/boot/efi also has two not-updated files:
linux64.efi.stub dated Sep 23
systemd-bootx64.efi dated Sep 30.
Hrm could you list the contents of /boot/EFI/org.clearlinux and cat /boot/loader/loader.conf, and all list all the files with their contents in /boot/loader/entries? systemd-boot can only can list what kernels have files in the entries folder.
btwarden, I think you’ve hit on it.
When the hanging issue started, I first tried to deal with it by booting from a USB stick and entering troubleshooting mode. From there (it’s been a while, but this is my recall), I mounted the root partition and ran swupd {update,diagnose,repair}. That would have filled /boot, as you say.
Currently, “sudo mountpoint /boot” on my system reports “/boot is not a mountpoint”, but my /boot unmounted is not empty. It has the EFI and loader directories as you mention, btwarden.
My system doesn’t have a “boot.mount” service, but I was able to mount the boot partition by
creating a dir /mnt/boot and running “mount -L boot /mnt/boot” . The directory there, yes, it has
the EFI and loader dirs with the 5.3.1-838 and 5.2.17-836 kernels that I saw.
Ok … to fix this, then, I’m doing the following.
Mounting the boot partition to /mnt/boot
Saving both boot dirtrees to the root partition, because I know the USB stick works, if reboot fails.
Copying in the /boot dirtree to the boot partition.
In more detail:
prep
1.1) save boot under root
mv /boot /boot.save
mkdir /boot
1.2) mount boot partition
mkdir /mnt/boot
mount -L boot /mnt/boot
1.3) copy boot partition to root
mkdir /boot.partition
cp -rp /mnt/boot/* /boot.partition
1.4) copy saved /boot under root into boot partition
rm -rf /mnt/boot/*
cp -rp /boot.save/* /mnt/boot
1.5) unmount boot partition and clean up
unmount /mnt/boot
rmdir /mnt/boot