I have all the kernels/modules/headers and source since 14.2 release on my system (as well as some custom ones). I've always wondered if one should upgradepkg (or installpkg and after successful reboot a removepkg) when Pat releases new kernel packages for security reasons. It seems that keeping the old kernel parts is like asking for intrusion if you should accidentally reload one of them. How do others manage the upgrade to latest Slackware official kernels, especially for security on the stable and previous stable release? Running+Past+PastPast or Running+past+original version release?

Opinions wanted.

Thanks.

I never use upgradepkg on kernel packages. I always keep at least the previous, known-working version available. Once I am sure the new version works as expected, I can then removepkg the old kernel version packages.

However, sometimes I am a bit delayed in my pruning of older versions, so they may sit there for a while, but that's out of laziness, and I always set my bootloader to default to the newer kernel, so even a power-outage and reboot (if my UPS were to die) would default to the newer kernel. (The only exception to that rule is if the newer kernel is a test kernel that I built... depending on the potential stability, it may not be my default until it is put through its paces -- but if it is one of Pat's updates, it will always become the default.)

2 members found this post helpful.

On stable releases and in case of a kernel upgrade provided as a security fix, I recommend to just follow the detailed instructions provided on the Slackware Security mailing list, see for instance the last ones.

I trust Pat and crew to provide safe upgrades.

PS In this email I don't see the instructions for elilo found in the previous one about a kernel upgrade, that I assume are still valid.

Also, if you use an initrd I suggest to keep a huge kernel at hand just in case.

If you use slapt-get, it has a --no-upgrade option to the --install target to install the package rather than attempting to detect if a previous version is installed and upgrading it (which is the default behavior). This can be used for installing kernel packages if you prefer to keep the previous ones, but, I digress.

3 members found this post helpful.

Be realistic, and compare the alternatives. Are you really such a clot that you would do that? If you aren't, stop worrying. If you are, you'll probably wreck your own system long before somebody else does it to you.

3 members found this post helpful.

I use slackpkg with 'DELALL=off' in /etc/slackpkg/slackpkg.conf. After running slackpkg, I do 'mv /var/cache/packages /var/cache/packages$(date +%Y%m%d)'. This maintains a local archive of packages that can be compared to dates in the ChangeLog.
I have a script that I run to prune the archive to the current and last package versions. As a Slackware subscriber, I have official media with original release files and emergency boot capabilities.

Thank you Didier and bassmadrigal for your input and thoughts. bassmadrigal I was planning to use installpkg and after proving that the new kernel and initrd works then use the removepkg of the older kernels, effectively resulting in an upgradepkg.

I also notice that Pat suggest using mkinitrd_command_generator without the -c flag, leaving the old modules in the initrd. If you upgrade all, effectively removing the old kernel parts, why leave them referenced in the initrd? Or am I missing something about what the initrd references?

For the locally built kernels, which aren't installed by package, is there any special steps to take other than deleting the /usr/src/linux-kernel# directory and the /boot/initrd-tree/lib/modules/?

When it comes to kernel-headers packages I read AlienBob "DO NOT REMOVE THE PACKAGE" in the "upgrade a Linux Kernel from Source" on slackbook.org, due to potential issue for glibc and compiling software. However, the security release would have you upgradepkg the kernel-headers, which effectively removes the old ones. So what is the value of leaving the old kernel-headers if Pat is saying to upgrade them and Eric is saying to leave them if building from source? Or is Eric's comment only related to IF you build from source your own kernel since you are not building kernel-headers in that process?

Thanks for the education. Cheers

Thanks allend - interesting approach to keeping the older versions.

Right now I'm looking like this, but wanted to clean-it up:
# ls /var/log/packages | grep kernel
kernel-firmware-20161211git-noarch-1
kernel-firmware-20170626git-noarch-1
kernel-generic-4.4.38-x86_64-1
kernel-generic-4.4.74-x86_64-1
kernel-generic-4.4.75-x86_64-1
kernel-headers-4.4.38-x86-1
kernel-headers-4.4.74-x86-1
kernel-headers-4.4.75-x86-1
kernel-huge-4.4.38-x86_64-1
kernel-modules-4.4.38-x86_64-1
kernel-modules-4.4.74-x86_64-1
kernel-modules-4.4.75-x86_64-1
kernel-source-4.4.38-noarch-1
kernel-source-4.4.74-noarch-1
kernel-source-4.4.75-noarch-1

I always keep a Slackware installation disc handy. I just reinstall the kernel off the installation disc if need be. I know it is not recommended to do so, but I almost always upgrade my kernel packages using slackpkg (call me lazy, fine). I have yet to run into any issues with the kernel upgrade process and I maintain Slackware installations on 3 laptops and 2 raspberry pi machines here at home.

I suppose if I had a production system I would keep the most current and one previous kernel package installed. After being certain that the newest updated kernel works as expected I definitely would remove the old kernel.

The only other time I keep a previous kernel installed is when I've built my own kernel from source and I am still testing to see if everything checks out.

4 members found this post helpful.

I do the same. Everything is working just fine here.

3 members found this post helpful.

Thanks everyone. I've upgraded per Pat's instructions and everything loaded without issue. Followed the instructions and also took a look at original disk FAQ, etc. for how to make sure huge was a installed backup. I also have the original disk. Appreciate the opinions. I also removed all the older kernels and found when I included the -c the /boot/init-tree was cleared and re-populated with 4.4.88.

Any more thoughts about my questions in post #6?

Cheers

kernel-generic, kernel-huge, kernel-modules, and kernel-source are parallel-installable, meaning when you can run installpkg, and the critical files are written to versioned locations. I guess it's user preference on what to do about the /boot/vmlinuz symlink. I usually edit my lilo/elilo config to point to the actual path of kernel I want to run on next boot. Usually I installpkg the kernel and modules, set kernel path and reboot, and cleanup old packages after testing the new kernel for a while. This is good, since it makes reverting simply changing a path as mentioned earlier in case of a kernel regression. I have seen bugs crop up, even on "stable" branches.

kernel-firmware, kernel-headers, and provide /lib/firmware and /usr/include/...linux stuff..., without versioning their paths. Running installpkg is ok, but you will overwrite whatever was down in there already installed by the older packages. I always upgradepkg these, since generally the old package is obsolete anyway.

There is not much reason to have kernel-source, unless you need to compile out-of-tree drivers, and this is one way to do it by using this package. Parallel installing kernel-source will just eat up alot of disk space.

Also, the old adage about never upgrading kernel-headers is not true anymore.

The kernel-headers packages are in-sync with the glibc{,-solibs} packages.
Is it changed now?

Hmm I was looking at /boot last night and noticed that the symlinks for System.map, config, and vmlinuz all point to the xxx-huge-4.4.88 rather than generic-4.4.88. I've setup the mkinitrd for kernel 4.4.88 but my lilo is specifically pointed to vmlinuz-generic-4.4.88 for the default boot and to vmlinuz-huge-4.4.88 for the selectable fail-safe fallback. Which made me think of another "why is that", i.e. does vmlinuz-huge-4.4.88 even require an initrd, or should it be initrd-less in lilo? In the release Installation HOWTO Pat suggest that the generic kernel needs the initrd, but doesn't say if initrd is needed for the huge kernel? Which brings me back to "why is that" that the system.map, config, and vmlinuz all point to huge kernel?

Oh and one more "why is that". Why wasn't there a new kernel-firmware? What is the purpose of kernel-firmware anyway?


Thanks again.

Long story short, they point to the huge kernel because that was the last thing installed (alphabetically). Each generic and huge kernel package have a doinst.sh file that creates the appropriate symlinks. Whichever one was last installed will override any previous symlinks. Since huge is later in the alphabet than generic, huge is installed later than generic and takes over the symlinks.

Now, to go into a bit more detail on your questions. No, in many cases, huge does not require an initrd (I think the main exceptions are if root is on an lvm and/or encrypted partition). System.map is really only useful for debugging the kernel, which most end-users won't be doing.

But, in general, this is why I never use the symlinks in my /etc/lilo.conf. If I happen to install a kernel in a different order than expected, my system may not boot. It is much easier to directly reference the kernel you want to boot rather than rely on a symlink.

And kernel-firmware is a bunch of proprietary blobs that are needed to make a lot of hardware out there function. This covers most video cards, a lot of wifi cards, and many other core components in the system. While there are semi-frequent updates to the kernel firmware repository, many won't be useful for the kernels that are included in Slackware. A lot of the newer firmware is targeted to newer kernel releases. Pat only updates this occasionally. But, if you happen to find that a newer firmware will be beneficial for your system, you can always grab the source from your favorite mirror and run the SlackBuild. It will grab the latest version from the kernel.org people and automagically package it into a Slackware package that you can then update over the old one.

2 members found this post helpful.

Wow, thanks bassmadrigal, that was a timely answer. I suspected the alphabetic order was the culprit. I also have lilo.conf specifically pointed to the vmlinuz-generic-4.4.88. Should I also change the symlinks for system.map and config or leave them alone?

And since my /root is on LVM/LUKS partition I do need the initrd for the fail-safe huge kernel, which is according to the "Installing Slackware on encrypted volumes" document on the installation disk. But thanks for the confirmation. There is so much to read and re-read even after you have the system up and running.