BIOS freezes upon boot - message "SHA256 validated"

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?

I did the following:

sudo swupd autoupdate
sudo swupd autoupdate --enable
sudo swupd autoupdate
sudo swupd check-update
sudo swupd update --version 31150
sudo reboot
sudo swupd check-update

as per bash history.

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.

No change. I’ve updated again. Did the above. Am now on version 31250. sudo clr-boot-manager list-kernels now says:

  • org.clearlinux.native.5.3.4-846

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:

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.

Check /usr/lib/kernel and run a sudo clr-boot-manager update

Done. No change in initial boot menu.

listing of /usr/lib/kernel:

tony@keller~ $ ls -lR /usr/lib/kernel
total 26720
-rw-r–r-- 1 root root 277 Sep 27 13:49 cmdline-5.2.17-836.native
-rw-r–r-- 1 root root 277 Oct 8 00:31 cmdline-5.3.4-846.native
-rw-r–r-- 1 root root 200755 Sep 27 13:49 config-5.2.17-836.native
-rw-r–r-- 1 root root 206126 Oct 8 00:31 config-5.3.4-846.native
lrwxrwxrwx 1 root root 31 Oct 5 10:14 default-native -> org.clearlinux.native.5.3.4-846
drwxr-xr-x 2 root root 4096 Jul 2 01:52 install.d
-rwxr-xr-x 1 root root 13392032 Sep 21 03:15 org.clearlinux.native.5.2.17-836
-rwxr-xr-x 1 root root 13539488 Oct 5 10:14 org.clearlinux.native.5.3.4-846

total 8
-rwxr-xr-x 1 root root 1712 Oct 18 2018 50-dracut.install
-rwxr-xr-x 1 root root 3384 Oct 18 2018 51-dracut-rescue.install

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.

This sounds like maybe files got written in the /boot directory of the root partition, while the EFI partition was not mounted there.

Try this to make sure /boot is empty when not mounted:

$ sudo mountpoint /boot
/boot is not a mountpoint
$ sudo ls -la /boot
total 8
drwxr-xr-x  2 root root 4096 Jul 18 08:29 .
drwxr-xr-x 19 root root 4096 Jul 31 15:46 ..

Then mount it and check for the expected kernels:

$ sudo systemctl start boot.mount
$ sudo mountpoint /boot
/boot is a mountpoint
$ sudo ls -lR /boot
total 1
drwx------ 4 root root 512 Jul 18 08:34 EFI
drwx------ 3 root root 512 Oct  9 09:06 loader

total 2
drwx------ 2 root root  512 Jul 18 08:34 BOOT
drwx------ 2 root root 1536 Oct  9 09:06 org.clearlinux

total 96
-rwx------ 1 root root 97634 Jul 18 08:34 BOOTX64.EFI

total 30149
-rwx------ 1 root root  1196031 Oct  1 15:40 bootloaderx64.efi
-rwx------ 1 root root  2479104 Oct  1 15:40 freestanding-00-intel-ucode.cpio
-rwx------ 1 root root    15384 Oct  1 15:40 freestanding-i915-firmware.cpio.xz
-rwx------ 1 root root 13535392 Sep 30 11:27 kernel-org.clearlinux.native.5.3.1-843
-rwx------ 1 root root 13539488 Oct  9 09:06 kernel-org.clearlinux.native.5.3.5-847
-rwx------ 1 root root   105830 Oct  1 15:40 loaderx64.efi

total 1
drwx------ 2 root root 512 Oct  9 09:06 entries
-rwx------ 1 root root  48 Oct  9 09:06 loader.conf

total 2
-rwx------ 1 root root 564 Sep 30 11:27 Clear-linux-native-5.3.1-843.conf
-rwx------ 1 root root 564 Oct  9 09:06 Clear-linux-native-5.3.5-847.conf

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:

  1. prep
    1.1) save boot under root
    mv /boot /
    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 /* /mnt/boot
    1.5) unmount boot partition and clean up
    unmount /mnt/boot
    rmdir /mnt/boot

  2. reboot

Reboot worked. I’m up to current now.
Did I miss anything?


thanks,cleaning /boot solve my issue too.