Must I blacklist my kernel when updating the parches in Slackware64-15.0?
 

I have been reading a lot of "How-to's" and threads in order to prepare myself for doing my first "grabbing" (I am not sure which verb would be correct: install? update?) of available patches for Slackware64-15.0. Which I intend to do via Slackpkg.

I am confused about some points.

In several articles there is reference to the sequence below as a good way to achieve what I am trying to do:
# slackpkg update gpg
# slackpkg update
# slackpkg upgrade-all
# slackpkgnew-config

But in many other articles I found reference to blacklisting 3rd party packages/repos and the kernel. Blacklisting of the kernel as way of keeping slackpkg from eliminating the present kernel. I think that this is to be the case when upgrading the system to a new release, but I am affraid to try applying the patches through slackpkg without blacklisting the present kernel if I don't ask here first.

If I blacklist the present kernel should I install the new kernel before applying the patches or after? Or does it not matter?

Must I take any special action regarding the aaa-base patch ? I mean like applying it before running the "uppgrade-all"?

If I install a new kernel, with a new initrd will a proper name to the new initrd guarantee that I will still have the initrd for the present kernel in case the new kernel for some reason does not boot ? Will there be 2 initrd-trees?

I am not able to answer these questions from what google provides me.

will be thankful for any tips.

Can some moderator move this thread into the proper Slackware sub-forum, and maybe correct the typo (parches -> patches) in the title? Thank you in advance.

Must I blacklist my kernel when updating the parches in Slackware64-15.0?
 

Are you using EFI?

I blacklist both generic kernel and modules but not kernel headers. Changing the headers doesn't cause any problems except possibly when you're building software locally, and it gives me a heads-up that there is a new kernel in the offing.

Upgrading the kernel in a BIOS-booting machine involves a small but finite risk that the new kernel won't work and you will then no longer have the old one to fall back on. It's not such a problem with UEFI booting because in that case you are probably using copies of the kernels on your ESP and not the original ones in /boot, which an upgrade would destroy.

But if you have upgraded the kernel modules, your rescue boot would still probably fail because it could no longer find its own modules.

It is a multiboot machine on Bios mode, works well with 10 different distros of which 3 are Slackwares.

Would it be any wise to copy some stuff to another partition, just in case?

Or could I have some stuff -like old kernel, old initrd and perhaps some more on a USB-stick and put it on the right place with a live usb if it was not a multilib machine ? In case the new kernel fails me.

That couldn't possibly hurt!
Why not use a standard rescue image like SystemRescueCD? Then you could boot from it and you'd have all the usual tools at your disposal without all the hassle. If you then keep copies of a guaranteed running kernel, modules and initrd in a safe place and use your rescue boot to copy them back and edit the bootloader, you could probably upgrade the whole lot without the risk of getting trapped. But I prefer the blacklist option -- it's simpler.

Thank you Hazel ! That was enough to reassure me to go on.

But I think I would also prefer blacklisting if I was sure that I would have a way out. I guess I have not understood the logic of the whole thing. If I understand you right then It might happen, although most unlikely, that if something went wrong I would be missing my old modules. That would be if I did not blacklist them, right? But if I blacklisted then , they would not be missing.

But my doubt is what if the new kernel fails? How do I boot then ? this is what I seem to be unable to find out from google and the likes. Will there be an initrd tree for the old kernel? there must be one for the new kernel if I install it myself (versus update/upgrade via slackpkg) at the right moment. Thus my question: can there be more than one intrd-trees in the boot folder? Or am I missinga a lot here?

I am thinking of blacklisting and copying stuff to be sure. I am still a newbie at Slackware. Reinstalling the whole thing is not much of a problem for me, but installing the 3r parties and reconfiguring the desktop to what I am used to is a daunting enterprise. Maybe I ought to search a solution for THAT! Never did it.

It's your responsibility to ensure that whatever bootloader you use has both options on it. For example, I use elilo (I have a UEFI machine) and elilo has a configuration file called elilo.conf. Because slackpkg/installpkg doesn't upgrade this, I need to do it by hand regardless of my update policy. I never change the boot stanza in elilo.conf; I simply add a new one for the new kernel. That means that I have the old one still on the boot menu just in case. If all goes well, I comment out the stanza I no longer need.

As to the initrd tree, you only need one because it isn't used in booting. It's only used by the mkinitrd script to create your initrd. Again, it's your responsibility to ensure that you have an initrd available for every kernel you want to boot.

I normally don't care if the update process chooses to update the kernel. But, also remember that you can simply copy the kernel-image file in /boot to some name that GRUB does not care about. Or, anywhere else you please.

You get that automatically with UEFI because the active boot files are on the ESP, not in /boot. You have to copy them over there by hand, but then they remain there until you delete them. They aren't touched by pkgtools.

It feels like I got it now. Understanding that initrd-tree is used when producing an initrd and not when using an initrd changed my life !

I will proceed now. With crossed fingers, of course.

Thanks you all for nice and prompt support. Amazing

Marking as SOLVED.

Coming back to my old thread
 

I am not sure I am doing the right thing, but I thought it would be silly to start a new thread to continue this discussion which I marked as solved and forgot about it for quite a while.

But now I have just installed "slackware64-live-daw-15.0" and ran:
my original "/etc/slackpkg/blacklist" said:
and

I don't understand why linux-5.15.139 was not installed under updating/upgrading-all. I had understood (here at this thread and more recently at https://www.linuxquestions.org/quest...ht-4175709694/), that the point of blacklisting a kernel was to prevent installation of kernel by slackpkg.

linux-5.15.117 packages were not blacklisted, so I expected them to be updated to 5.15.139.

I think I am missing some point here and that I need a clue, which I will be grateful for.


Edit:My problem with kernel updating was mentioned as a side question on a more recent thread https://www.linuxquestions.org/quest...os-4175731550/which did not seem to raise as much interest as this one once did.

I did read http://docs.slackware.com/slackware:beginners_guide yet another time as suggested there, before returning here, but found no comfort there.

Which mirror are you using, and is it up to date?

I'll just point out that you seem to have dots where there should be dashes, eg:

You have: kernel-generic.5.15.19

It should be: kernel-generic-5.15.19

You can't put version numbers in blacklist, they won't work. Only the package name:
What is the package name?
So, you can't define blacklisted items with more precision. Less precision is possible using regular expressions, for example
blacklists all these packages: