Should the lxpanel Updater be used for the kernel and bootloader?

Question

TL;DR:

As of this writing, the lxpanel Updater applet somehow only updates the kernel modules without changing the system release. I want to know why, and point out that apt resolves issues.

Backstory:

Today, I installed the following updates using the Updater applet in the lxpanel menubar on RPi OS:

apt list --installed | grep 202208

linux-libc-dev/stable,now 1:1.20220811-1 arm64 [installed,automatic]
raspberrypi-bootloader/stable,now 1:1.20220811-1 arm64 [installed]
raspberrypi-kernel/stable,now 1:1.20220811-1 arm64 [installed]

After rebooting following the prompt, I noticed the following symptoms:

1. My second monitor is stuck on the rainbow startup screen. Replugging it and checking xrandr show that it's not detected.

2. None of the daemons started by kernel modules were running.

After Ctrl+Alt+F1ing into tty1, I see at the top:

[    3.003542] systemd[1]: Failed to start Load Kernel Modules.  
[FAILED] Failed to start Load Kernel Modules.

with the rest of the normal login screen below that, indicating that I successfully booted using Kernel 5.15.32-v8+.

Resolution:

I realized the recently updated kernel modules were version 5.15.56, while the system was still at the previous version I mentioned earlier. Based on this question, I reinstalled the kernel updates using apt-get (rather than the lxpanel updater) and rebooted, resolving the problems. This RPi forum thread demonstrates the same procedure with apt, which is more current.

Takeaway

As mentioned earlier, the lxpanel Updater applet somehow only updates the kernel modules without changing the system release.
Why is this? Should I be using apt instead of the Updater applet for kernel updates?

Answer 1

the lxpanel Updater applet somehow only updates the kernel modules without changing the system release

I think the more likely explanation is that you are mistaken, or something went wrong.

Let's have a look at some of the files that are installed by package raspberrypi-kernel:

> dpkg -L raspberrypi-kernel

/boot/COPYING.linux
/boot/bcm2710-rpi-2-b.dtb
/boot/bcm2710-rpi-3-b-plus.dtb
[...]
/boot/kernel8.img    <==================  The kernel
/boot/overlays
/boot/overlays/README
[...]
/lib/modules
/lib/modules/5.15.56-v8+
/lib/modules/5.15.56-v8+/kernel  <======  The modules
/lib/modules/5.15.56-v8+/kernel/arch
/lib/modules/5.15.56-v8+/kernel/arch/arm64
[...]

The final ellipse there is the long list of kernel modules. In other words, the same package is responsible for installing both the kernel (this is a 64-bit system and so there is just kernel8.img) and the version specific set of modules that goes with it necessary for full functionality.

I realized the recently updated kernel modules were version 5.15.56, while the system was still at the previous version I mentioned earlier.

This happens because the previous kernel version modules directory was removed. That can be a problem if the system is not then rebooted, which is definitely a flaw in the way the Pi specific package is put together and deployed. You've said that you rebooted, however. I first ran into this problem because I used to leave the boot partition unmounted, and so updates would copy the new kernel into the /boot directory, which, if there is no partition mounted there, is just a normal directory, and so the new kernel that is put there will not ever get used (you can mount a partition on a directory with content already there, but that content will then be inaccessible until the mount is undone).

You can check if this has ever happened on the system by unmounting the boot directory and looking at what's there.

sudo umount /boot
ls -l /boot

If that lists anything, it is stuff that was accidentally copied in there by an update run with the partition unmounted.¹

Note that other than accommodating updates and easy access to config.txt etc, the boot partition doesn't need to be mounted at all. Nothing in there is actually used once the kernel is loaded.

Whether or not this is the case, while I have never used the GUI updater, I find it hard to believe that it somehow splits up a distro package and installs only part of it as standard behaviour. I doubt apt itself can do that, so it might actually require a custom backend (= more ridiculous).

My point is that either what seemed to happen did not happen, or something failed during the process, so the answer to the question:

Should I be using apt instead of the Updater applet for kernel updates?

Is either you might as well, or else you should not be using it at all: If the applet is really prone to doing half an update then not alerting the user and/or rolling back the system, it is a broken tool.

It's also possible of course that this iteration of the package update was broken. I ran it to check, however, and after a reboot everything was fine:

> uname -r
5.15.56-v8+

---

1. That the raspiberry-kernel package doesn't do a check or something for this is one of the reasons I've called it "flawed". The other is that the previous module directory doesn't need to be removed; the norm on other linux distros, as far as I've ever noticed, is to leave them for at least one more update, which would greatly diminish the chance of ending up with a system running a kernel whose modules have been deleted.