Upgrading the kernel in Slackware10 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
slackpkgdoes 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 procedureThe 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-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
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
/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 cleanupAt 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 upIf 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