Upgrading the kernel in Slackware

10 December 2022
As a general rule Slackware's advice when it comes to upgrading the kernel comes down to a single word: Don't. This is because it is one of those things that slackpkg does not fully automate so without manual intervention the probability of a non-booting system is exceptionally high. Nevertheless since I was upgrading a system from a beta version of Slackware 15.0 to the production version I had reason to do this, but as there was no definitive guide I decided to write up how I did it. Be warned though — while Slackware itself is aimed at advanced Linux users this procedure is aimed at advanced Slackware users.

The procedure

The underlying idea is to install the new kernel package in parallel with the existing one, so if the new one breaks it is possible to boot using the old kernel and roll things back. Firstly see what the existing kernel version is:

# ls -ltr /boot/ | grep vmlinuz -rw-r--r-- 1 root root 11121152 Nov 3 2021 vmlinuz-huge-5.15.0 -rw-r--r-- 1 root root 7447008 Nov 3 2021 vmlinuz-generic-5.15.0 lrwxrwxrwx 1 root root 22 Nov 3 2021 vmlinuz-generic -> vmlinuz-generic-5.15.0 lrwxrwxrwx 1 root root 19 Nov 3 2021 vmlinuz-huge -> vmlinuz-huge-5.15.0 lrwxrwxrwx 1 root root 19 Nov 3 2021 vmlinuz -> vmlinuz-huge-5.15.0

In my case the existing kernel was huge-5.15.0 so I created a backup entry within /etc/lilo.conf that points to it directly rather than using the symlink:

# Linux bootable partition config begins image = /boot/vmlinuz root = /dev/sda1 label = Slackware read-only # Partitions should be mounted read-only for checking image = /boot/vmlinuz-huge-5.15.0 root = /dev/sda1 label = 5.15.0 read-only # Partitions should be mounted read-only for checking

The next stage is to install the new kernel packages in parallel and this is done by using the following command. If your existing kernel is a generic one substitute kernel-huge with kernel-generic although I have never had a system that used the generic kernel.

# slackpkg download kernel-huge kernel-modules

In the next screen select the updated version of the two packages, which in this case were huge-5.15.80. Once these have been downloaded they need to be manually installed.

# installpkg /var/cache/packages/patches/packages/linux-5.15.80/kernel-huge-5.15.80-x86_64-1.txz # installpkg /var/cache/packages/patches/packages/linux-5.15.80/kernel-modules-5.15.80-x86_64-1.txz

Afterwards run /sbin/lilo and upon reboot the new kernel should be used by default. If things mess up select the alternative (i.e. older) kernel from the boot screen and change the default kernel back to the old one.

A bit of cleanup

At this point there are two versions of kernel packages installed which the Slackware package manager does not like:

# slackpkg upgrade-all Checking local integrity... DONE You have a broken /var/log/packages/ - with multiple versions of the same package. The list of packages duplicated in your machine is shown below: kernel-huge-5.15.0-x86_64-1 kernel-huge-5.15.80-x86_64-1 kernel-modules-5.15.80-x86_64-1 kernel-modules-5.15.0-x86_64-1 You can (R)emove one or more of, or (I)gnore these packages. Select your action (R/I):

At this point go ahead and remove the older packages and in the process I would also upgrade all the kernel packages. Because the newer kernel packages were manually installed the package manager thinks the “current” version is the older version so will want to perform an upgrade — it is a pain but it easiest to just let it get on with it. Don't forget to remove the backup /etc/lilo.conf entry and re-run /sbin/lilo once it is done (hint: I did forget..).

If things mess up

If like me you messed up and forgot to run Lilo you may well end up with a screen much like the one below. It is not that hard to fix but it can be a right pain if it is a server system that does not normally have a keyboard and display attached, which in my case is more often than not.

The solution is to boot the system using the Slackware installation disc and repair the Lilo setup manually. These days it is unusual to have a seperate /boot partition so assuming the root partition is on /dev/sda1 it needs to be mounted somewhere convenient:

mount /dev/sda1 /mnt

The next stage is to build a chroot jail that represents the actual installation and then run Lilo within it, which is done using the following commands. The first three setup various system block devices, the fourth creates the chroot jail itself, and finally there is the call to Lilo to fix things up. You might need to edit /etc/lilo.conf in the process, depending on what was forgotten to be done.

mount -t proc /proc /mnt/proc mount --rbind /sys /mnt/sys mount --rbind /dev /mnt/dev chroot /mnt /sbin/lilo

Remarks

This is one of those occasions I was doing something risky to start with, and in the process messed up so had to work out how to dig myself out of the hole, and this article is the result. I forget when this machine was actually built but since it was using Slackware Current from when Slackware 15.0 was in beta I guess it could have been this time last year. I needed to migrate it over to the release version of Slackware 15.0 and since the server itself had not been fully comissioned took the risk of upgrading all packages. I had forgotten the RAID drives had already been setup but since all the operating system stuff was on a seperate solid-state drive, a clean reinstall using the release Slackware 15.0 would not have been a major disaster.