I would like to know how often it really happens that a new kernel does not boot. I must admit that i am using the huge kernel and never had any issues with it, neither on stable nor on -current. I can imagine that an upgrade could eventually cause issues when one is using LVM / Full-Disk-Encryption or things like that.

For me the the main issues when using the -generic kernel is that I always have to remember to run lilo afterwards, which I sometimes forget and then (and only then) I have to boot the old kernel and fix the initrd.

So I am really interested in your real-life experience and would be happy if you could share some of the situations you had on kernel upgrades.

LVM / Full-Disk-Encryption is my use case. I can't afford have no way around with a faulty new kernel. It never happened before, but who knows when...

That's the reason why I decided to automate it and to keep the previous working kernel. Before that I had a TFTP server at home so I could boot to the rescue image and fix things, which also involves to mess with BIOS network and boot settings as I always keep my notebook pretty closed to booting with anything I can't control. There was one time I was away from home. You could imagine the rest. My current approach gives me all the tools I need to recover from a faulty upgrade, anywhere.

I've been using my own Slackware upgrade scripts since last year. At that time I had 3 systems on current and the kernel upgrades were becoming robotic for me. Hopefully the scripts are ready for others to test drive. I named the scripts "autoslackpkg".

https://www.go4it2day.com/news/autoslackpkg-0.4.html

The scripts leverage slackpkg and manage kernel changes from start to finish on both EFI or LILO systems. The key to successfully using the scripts is to make sure 4 config files are appropriately customized. There are rudimentary help screens that try to explain the config customizations.
I use the scripts on 11 systems currently, 14.2 & current, x86 & x86_64, desktops, servers, gateways & LXC containers. I've tried to hit all my edge cases but I'm sure there are others I haven't run into yet. You're welcome to use them or tear them apart for ideas for your own scripts.

Enjoy!

3 members found this post helpful.

That is absolutely correct, but when I mentioned the "previous" kernel, I actually meant the earlier build of the $KCUR version. That will, obviously, get overwritten. Any earlier kernel versions that are still installed will, clearly, not be touched. Should the new build, for any reason, fail to boot up, then you can still fall back on such an older version - PROVIDED that you kept at least one of those.

Sounds like a great suggestion, and would make such a fallback a whole lot easier, should it ever be required. I'll look into it. Sure seems pretty much doable anyway.

I had some spare time today and could face the kernel build bump problem in my script. Follow are the results (with mocked values, of course).

First with a regular kernel upgrade, e.g. 4.19.66 to 4.19.67:

Now with just a kernel build bump, e.g. 4.19.66-1 to 4.19.66-2:

Now let the kernels come so I can found the bugs in my logic...

1 members found this post helpful.

Hmmm... I have just tried the following (while “kernel-source-4.19.66-noarch-1” was the highest kernel-source version installed):
It doesn’t do what I intended, though, in that it removes all earlier versions of the kernel-source package, then installs the specified new package. Come to think of it, this doesn’t really come as a surprise; after all, it just performs the upgrade that I request—which, by definition, will remove all earlier versions of the package to be upgraded.

Thus, a sequence of ‘removepkg’ and ‘installpkg’ will be the way to go in order to upgrade an installed kernel version to a newer build.

Only if you want to keep the previous working kernel and its source so you can recompile it for any reason. But kernel-headers won't work that way, as it always replace the previous files.

My approach is a little different: although I keep the previous kernel, I do so only to count on a booting system in case the worst happens, i.e. the just installed new kernel won't boot at all. As I have no intention to recompile the previous kernel, nor compile anything in the system against it anymore, I don't need kernel-source nor kernel-headers of the previous kernel.

As such, when a new kernel arrives (like 4.19.67 to replace 4.19.66), my script just upgradepkg kernel-source and kernel-headers, effectively replacing them with the newer versions. On the other hand, when the kernel upgrade is just a bump (like 4.19.66-1 to 4.19.66-2), there is no need to touch kernel-source and kernel-headers, so my script just skip this step.

In any case, version or bump upgrades, my script actively removepkg the selected kernel then installpkg the new one. I prefer this way to avoid conflicts that may left orphan files or dead links around in the system.

1 members found this post helpful.

Good catch… looking at it like that, I don’t actually need the older sources or headers either.
For now, it doesn’t hurt to keep them around either, but I’ll think it through a little further before I make up my mind about how to handle them in the future.

Indeed, you'll wipe out the earlier versions… which are, in effect, just dead weight when you leave them installed.

That idea hadn't even crossed my mind just yet, but you're absolutely right!

I think I’ll experiment a little further to see what works best for me… but your comments certainly make sense. In any case, I remove the links that come with a kernel installation, and I create and maintain my own set of links—so far, without issues.

I do have an updated version of my script ready now, which maintains an additional set of links to the ‘previous’ kernel files (i.e., to the kernel version that is running when the script is being executed), but I’ll have to double-check that it doesn’t do any crazy things when it has to remove kernel packages.

Attached to this post is an update to my ‘upgrade-kernel.sh’ script.

NEW FEATURE:

• The script now maintains a set of symlinks to the “previous” kernel version—i.e., the one that is active at the time a new kernel is being installed. These symlinks will have the same names as their “new-kernel” counterparts, but with a suffix of ‘-prev’ appended.

Caveat: When you remove one or more kernel versions while no new kernel version is available, these ‘-prev’ symlinks will be recreated to point to the kernel version that is running at that time. As a consequence, if you’re running the latest installed kernel version at that time (which you normally will), then the ‘-prev’ and the “new-kernel” symlinks will both be made to point to that latest version. I don’t consider this a significant problem, because:

1. the primary goal of the script is to install kernel upgrades—at which time it will let you remove any versions that you no longer want to keep;
2. the currently active kernel is known to be good anyway, since otherwise you wouldn’t be running it in the first place.

TO DO:

• Add support for installing a new build of an already installed kernel version.

I will be testing this support on my Slackware-current install, which I temporarily reverted back to kernel version 4.19.66, Build 1. I’m using a test version of the script that I point to what it thinks is my local repository mirror, but is in reality a simple folder into which I can copy any kernel version and build that I want to test with.

Attached Files

upgrade-kernel.txt (83.5 KB, 17 views)

2 members found this post helpful.

Kernel 4.19.68 upgrade handled as usual. Now let's wait for a bump (e.g. 4.19.68-1 to 4.19.68-2) to test this case. It may take years though.

Attached to this post is the next update to my ‘upgrade-kernel.sh’ script.

NEW FEATURE:

• The script now supports installation of a new build of an already installed kernel version.
  To install a new build of the latest installed kernel version, it will first install the new build, and next remove the previously installed one. In this way, the removal operation is really only required in order to clean up installation registration of the overridden (and overwritten) build.

KNOWN ISSUE:

• It remains a bad idea to remove the latest installed kernel version, since the version-independent symbolic links to the kernel files will then be left behind, but they will become “dangling” pointers—i.e., they will point to ‘nowhere’.
  Note that the script won’t even let you remove the latest kernel version anyway, unless you are running an earlier kernel version and there is no new kernel available for installation.

EXTRAS:

• Script ‘fix-kernel-symlinks.sh’ will recreate the version-independent symbolic links to the latest installed kernel files.
  It will also allow you to select the kernel version to which you want to point the fallback (i.e., “previous”) symbolic links.
• Script ‘rebuild-kernel-initrd.sh’ allows you to select the installed kernel versions for which you want to rebuild the Initial RAM Disks (“initrd”).

Attached Files

	upgrade-kernel.txt (94.3 KB, 28 views)
	fix-kernel-symlinks.txt (12.2 KB, 25 views)
	rebuild-kernel-initrd.txt (13.8 KB, 24 views)

2 members found this post helpful.

Thank luvr, I am going to try it out soon and give some feedback. The dangling symlinks is not so much an issue in my point of view.

Could you elaborate a bit more why exactly now three scripts are needed instead of one like before? Wouldn't it be possible to merge all the functionality into the main script?

The main script, ‘upgrade-kernel.sh’, is the only one that’s needed. The other two, ‘fix-kernel-symlinks.sh’ and ‘rebuild-kernel-initrd.sh’ are just quick hacks that should not be required, but that can be used to repair anomalies with the symlinks or the initrds, should that ever be necessary. The ‘fix-kernel-symlinks.sh’ script for instance, will fix the “dangling pointer” issue for you, should you ever run into it.

I used the ‘fix-kernel-symlinks.sh’ while I was developing the latest version of my ‘upgrade-kernel.sh’ script, so I could verify if the latter behaved properly under various conditions. I haven’t encountered a situation in which the ‘rebuild-kernel-initrd.sh’ was useful, but you never know.

Thus, to recapitulate: Under normal conditions, you should still only really need the main ‘upgrade-kernel.sh’ script.

Thanks for pointing that out. I have to add some options to the mkintrd generation. Can I just modify the following line to look e.g. like this:

$(/usr/share/mkinitrd/mkinitrd_command_generator.sh -a -l sg-latin1 -h /dev/cryptvg/swap '-o '"${INITRD}" --run "${KERNEL}")

Greetings

Lioh

Yes, that will work fine.