It is clear that removing the system's live kernel and modules, while upgrading packages, can result in nasty situations.

May the user fails to properly update the bootloader, and some services may behave erratically without the live kernel modules on shutdown.

Like you known already, the "upgradepkg" script executes for every package a flow like: installing the new package, removing the old one, then (re-)installing the new one.

My idea is very simple: to stop this flow after initial installing of the new package, when its name is part of this certain list
The final result of this change is that "upgradepkg" will always install those particular packages along with the existent ones, instead of "upgrading" them.

This way, even on a mass upgrade of packages, will leave the current kernel (and its modules) functional, leaving to the user the choice to configure the bootloader as he wish, for example inserting a new boot entry for the new kernels, etc..

BUT, the main advantage is that the administrator can do a clean reboot on the new kernel, with the ability to preserve and the previous one as backup, then eventually to remove "manually" the old ones.

For the records, a similar policy of install/remove only but not to "upgrade" for the runtime kernel packages is used from long time also by the major distributions like RHEL (and Fedora), (Open)SuSE, Debian (and Ubuntu or Mint).

The common approach by many Slackers is:

1. Exclude kernel updates with slackpkg.
2. Manually use installpkg to install newer kernels.
3. Run mkinitrd with the new kernel.
4. Manually edit the boot loader to support both kernel versions.

This is one aspect I think other distros do better. With other distros, multiple kernels are preserved so a new kernel cannot prevent booting the system. Also, slackpkg does not support GRUB, which I think more than a few Slackers use these days. I can live with the above steps but I much prefer the way other distros handle kernel updates.

1 members found this post helpful.

A few days ago when running experiments on a throw-away Slackware installation, I was being lazy and trying to figure out if I could get slackpkg to "install" the officially updated kernel for Slackware instead of having slackpkg "upgrade" the kernel files. I couldn't see a way for slackpkg to do that so I just duplicated the affected kernel files/directories, let slackpkg do the kernel "upgrade", then cleaned up lilo.conf and links to make original kernel available.

On my lazy days I wish I could use slackpkg to "install" official Slackware kernel updates keeping the already installed kernel(s)

However, I don't generally approve of having software utilities behave differently based on file/module name. I prefer using an option/switch, perhaps with a warning when run in interactive mode, than hidden content/name dependent logic. That path does NOT lead to clean code as exception after exception is added through the years.

I like the idea behind this since this is a semi-frequent issue we see on the forum, however, I feel this would "muddy the waters" of what upgradepkg is designed to do. upgradepkg is one of those "raw" packages that should do just what I tell it to do. You'd also run into the problem of users never using the upgraded kernel and they'd still be running the kernel that was shipped with the Slackware version they're using.

Plus, I feel like most users use slackpkg to keep their systems upgraded, which is a lot more user friendly and is probably a better place to instigate something like this (the users who use upgradepkg manually are more likely to remember to handle their kernel upgrade and/or fix their system when something goes wrong). I personally think that /etc/slackpkg/blacklist should have the kernel portions uncommented by default. An alternative (or addition) could be to have slackpkg modified to run installpkg instead of upgradepkg when it comes across those packages or to keep the packages blacklisted by default but notify them when a kernel update was available in the changelog, but I realize that's extra work to code and I'm not willing to put in the time or effort to do it.

But to change upgradepkg to not actually upgrade some packages seems like the wrong direction to me.

This is horseshit. The only person able to update the kernel on a default Slackware system is the system administrator. If the system administrator screws up, there the blame lies.

10 members found this post helpful.

seems I did a lot wrong in the past.
always used slackpkg update , slackpkg upgrade-all
if there was a new kernel, it was installed,
manualy boot entry of course, if, than also initrd, but I became lazy recently and boot the huge kernel.
just works, never had any problem,

Yup, I'd be interested to know if anyone has actually run into issues on -stable Slackware using the default approach. You only get into potential trouble when you start editing the vmlinuz* symlinks, edit lilo.conf to not point to them, or forget to run lilo. Of course, that's enough failure modes to warrant keeping backups of old kernels.

The proposed behavior is not within the scope of what upgradepkg is intended to do, or will ever do.

12 members found this post helpful.

We've had a few kernel upgrades on 14.2: 4.4.14 => 4.4.88 => 4.4.111 => 4.4.115 => 4.4.118 => 4.4.132. And I've used slackpkg update and slackpkg upgrade-all for all of them. Used mkinitrd_command_generator.sh to create an initrd for the new generic kernel, edited lilo.conf, and ran lilo before rebooting into the new kernel. No problems. Could it be something to do with them all being 4.4.* ? If I was building my own kernel I would keep the old reliable one, just in case.

1 members found this post helpful.

I agree with volkerdi, write programs that do one thing and do it well.

personally i do the same as upnort. blacklist kernel and install the new kernel alongside the existing.

I agree with the aim and the rationale. About the implementation, I favor using the tool that provide downloading and applying the update, possibly tentatively through a wrapper script. I plan to do that with slapt-get in Slint, I assume that this could be done with slackpkg in Slackware.

https://rg3.github.io/slackroll/ will install new kernels instead of upgrading them. (It also treats glibc-solibs, sed and pkgtools upgrades special.)

2 members found this post helpful.

Interesting. I didn't know about slackroll. I might have to give it a try sometime if I get bored.

On a -stable system I have never had problems when upgrading the kernel with slackpkg. It always worked as expected. I would just rebuild initrd for the new generic kernel and take care of lilo.conf. On -current, however, it has happened that the new kernel does not boot. Luckily I had a custom built kernel (the latest release candidate at that time) that I could use. I don't know what was wrong, but the issue was gone with the next kernel update in -current. But... it is -current, some issues are expected.