@luvr. I am actually not sure what caused this situation but currently the following broken symlink has been created:

initrd-*-prev -> initrd-*-4.19.80*

I have used the script for the first time on a newly installed system and this link has been generated on the first kernel update. The 'old' initrd was named just initrd.gz, maybe that's the root cause.

What a coincidence... I have just run into the same issue myself. It happens because one of the patterns to find existing initrds does not find any files and thus returns just the pattern unchanged.

I now have an updated version of the script available, which I will upload later. (I don't have my Slackware system handy at the moment, but the solution is as simple as inserting an appropriate "shopt" command near the top of the script.)

Thanks for reporting this issue. It reminds me to upload the new version.

Thanks for the reply. I will wait for the updated version. As far as I understood this can only happen on the first run/migration to your script.

Yes, that's correct.

Attached to this post is the next update to my ‘upgrade-kernel.sh’ script. It fixes a bug where, the first time that it is run on a freshly installed Slackware system, it will create a broken symlink, such as:
(where the version string, ‘4.19.81’, will be replaced by the actual kernel version, of course.)

To fix this bug, the script now sets the ‘nullglob’ shell option when it begins execution:
(Previously, this option got set in one of the functions defined in the script, but the function was called too late to prevent the broken symlink.) As the bash man page explains, the ‘nullglob’ shell option allows patterns that do not match any files to expand to a null string, rather than themselves.

As before, only the main script, ‘upgrade-kernel.sh’, is required.

Helper scripts ‘fix-kernel-symlinks.sh’ and ‘rebuild-kernel-initrd.sh’ let you recreate the symbolic links to the installed kernel files and rebuild the initrd, respectively, just in case.

Attached Files

	upgrade-kernel.txt (94.2 KB, 47 views)
	fix-kernel-symlinks.txt (13.1 KB, 20 views)
	rebuild-kernel-initrd.txt (14.7 KB, 18 views)

Thanks for the update. I am still thinking if there is a better way to handle System.map files. I have opened another thread to clarify this topic https://www.linuxquestions.org/quest...53#post6054053

Right now you are creating symlinks System.map-generic, System.map-generic-prev, System.map-huge and System.map-huge-prev. None of them will be used e.g. by klogd. It is okay to manually create a symlink System.map pointing to the correct version if debugging is necessary, but maybe a convenient default could be added. E.g. if a default kernel is set in lilo.conf an according System.map symlink could be created.

Another feature request would be to add elilo / UEFI support, which could be a bit more difficult as the Kernel and the initrd have to be copied over to /boot/efi/EFI/Slackware/ and according symlinks have to be generated there.

1 members found this post helpful.

Hmmm... I don’t think I would have my script look into the ‘lilo.conf’ file, if only because I don’t use it. (Furthermore, when you run ‘/sbin/lilo’, you can specify a different configuration file, so, I cannot even be sure that ‘/etc/lilo.conf’ will be the right place to look.)

Having said that, creating a ‘System.map’ link does sound like a good idea that I may want to look into—perhaps by looking at the type of kernel that is currently running and using that to determine the target for the link?

Sorry, but for now, that is something that I won’t implement, because all my computers run Legacy BIOS. The only UEFI computer that I’m supporting currently, is my dad's laptop, which dual-boots Ubuntu and Windows 10 (although he appears to be using Windows 10 less and less; I think he needs it only to update his TomTom GPS these days).

Fair enough, I just got some deviced which do not support Legacy Boot anymore (UEFI-only). Currently I use a custom kernel on that so it's not so relevant to me.

Now that Linux kernel 5.4-rc6 has arrived in -current testing, there is a new case where my upgrade script failed. I have managed to correct it. The corrected revision is here.

1 members found this post helpful.

@luvr I have one question on how you handle the -prev Kernels. E.g I had both 4.19.80 and 4.19.81 installed. After the upgrade to the 4.19.82 Kernel from today, the -prev links has been set up to point to 4.19.80. Is there a reason why they did not point to 4.19.81?

1 members found this post helpful.

Unless there's a bug in the script, you must have been running 4.19.80 at the time you ran the update. I reasoned that the "-prev" links should point to a kernel version that is known to work, so the currently running one looked like the most appropriate candidate to me.

Ah, think I was running a custom kernel while doing the upgrade. I think I have to monitor it a bit more.

Just out of curiosity whilst their is talk of updating.

I assume its perfectly normal / acceptable to have different versions of an application from 64 + multilib?


[ Status ] [ Repository ] [ Package ]
installed multilib mariadb-compat32-10.4.8-x86_64-1compat32
installed slackware64 mariadb-10.4.9-x86_64-1


On kernel talk

I assume (Again) best practice to keep the previous version + the new one so its easy to switch? Now apart from installing Slackware I don't have much knowledge on Kernels etc

On a new install I usually switch to a generic kernel / create an initrd and update elilo.conf.

If I upgraded to a newer kernel

[ Status ] [ Repository ] [ Package ]
upgrade slackware64 kernel-generic-4.19.81-x86_64-1 --> kernel-generic-4.19.82-x86_64-1

Do I need to create a new initrd based on the new generic kernel? If so how do I keep the old one for the older kernel?
If I dont need to create a new initrd I assume just copy over the kernel to /boot/efi/EFI/slackware and update elilo with the new details whilst keeping the old one?

Apologies if I have hijacked the thread, My previous thread contains my delight in gaming on slackware, and right now the whole slackware is in a nice state of play

It would be better to open a new thread on this but in general you have to upgrade the initrd on every kernel update. The script luvr provided does support this scenario for lilo, not elilo. If you want to keep different Ramdisks in place you have to name them accordingly: initrd-generic-4.19.81.gz initrd-generic-4.19.82.gz and refer to them in your elilo.conf. If you don't care about keeping the old kernel and just want to make sure that the initrd is automatically created and copied over to the EFI partition, you might want to take a look at zerounos approach for slackpkg: https://www.linuxquestions.org/quest...0/#post5849061 (read the 1st post as well).

1 members found this post helpful.

Yes, you do.

Just make sure you name it differently. For instance, use the kernel version as part of the name, or rename the old one to something like 'initrd-old' or some such.