Hi,
I've a question about kernel patches on Slackware 14.2 stable.
I would like to have three entries at boot on lilo, one for the default installation kernel and the others for the last two kernel updates. For example, the situation could be this one:

• 4.4.19-generic-smp
• 4.4.14-generic-smp
• Linux (default entry after clean Slackware installation)

The question is: can I add the entry for the 4.4.19 without overwriting the set of kernel packages of the 4.4.14?

I know I can upgrade from 4.4.14 to 4.4.19 by following these steps:

1) Blacklist these packages in /etc/slackpkg/blacklist:

• kernel-generic
• kernel-generic-smp
• kernel-huge
• kernel-huge-smp
• kernel-modules
• kernel-modules-smp

2) Install the new kernel packages with installpkg in order to avoid breaking the current installation

3) Create the initrd for the 4.4.19 with a different name respect to the 4.4.14 and add the respective entry into /etc/lilo.conf.

But, as I asked before, if I want to have both 4.4.14-generic-smp and 4.4.19-generic-smp installed in parallel? What could be a good procedure to achieve this result?

Thank you in advance for your time.

You have it pretty much figured out. As long as you don't use upgradepkg on the kernel packages, they will all sit nicely on the same machine.

The only thing you need to do is add extra lilo entries for the different kernels and ensure when you create new initrds that you don't overwrite the previous one. You can do that using the mkinitrd_command_generator.sh script (just replacing the two kernel versions in that command with the kernel you desire).

Then you ensure you have a stanza in your /etc/lilo.conf that points to each kernel and initrd you want listed (you can have kernels installed that aren't referenced in your lilo.conf). You may need to adjust the root option if your root partition does not reside on /dev/sda2.

Once you've edited your lilo.conf, test it by running lilo -t (a warning about LBA is normal). If there are any errors, see if you can figure them out and try again. Once you have a test run without errors, go ahead and save it by just typing lilo and hitting enter. Once it's saved, you can reboot and select your desired kernel.

1 members found this post helpful.

Hi bassmadrigal,
thank you for your answer.

I've another question which maybe goes a bit more in depth. When I use slackpkg to upgrade Slackware packages, I skip only a part of the whole set of the kernel packages (the blacklisted ones, as said above), but kernel-headers, kernel-firmware and kernel-source are upgraded to the new versions, since they are not blacklisted.
In this case, I'll have, for example, the kernel 4.4.14 with kernel-headers-4.4.19. What if, in a certain moment I'm running the 4.4.14 and I want to install a package which requires kernel-headers-4.4.14 (I can think of Oracle VirtualBox)?

Should I add these three remaining packages (headers, firmware and source) to /etc/slackpkg/blacklist and install the new ones with installpkg? Can they live together with the oldest ones?

Unlike the image and the modules, kernel-headers live in /usr/include regardless of kernel version, so you cannot have several versions side-by-side. If you must have specific headers, you will need to upgrade the package. The risk of ABIs blowing up while running a kernel that is older than the headers does exist in principle, but many people, including kernel devs and distro maintainers, disregard it in practice. And actually, if I understand it correctly, all the things compiled against stable release headers would carry the same risk (that includes almost everything in your installation).

The situation with the stock firmware packages is similar, but there it's even more safe to use whatever is the latest.

1 members found this post helpful.

The kernel headers package really isn't what most people imagine, it's more closely related to glibc than anything else. You generally want to match whatever Pat puts out. As qweasd mentioned, it's usually not a big deal if you're running a different kernel than the kernel-headers package installed.

Most programs that require the actual kernel headers (usually 3rd-party modules like proprietary drivers or virtualbox modules) will reference the headers in /usr/src/linux-$VERSION/, not the ones in /usr/include/linux/.

And the kernel-firmware package is just the latest firmware pulled from kernel.org (or at least the latest at the date released). You generally want the latest version of that, and there generally isn't issues using different kernels with it.

1 members found this post helpful.

bassmadrigal and qweasd, thank you for your answers.

So, just to summarize, it's sufficient to make the steps described in the first two posts of this thread. Is it right?

At the moment I'm running Fedora on my laptop. I think I will try to (re)install Slackware next month.

Yes And you can safely upgrade kernel-headers and kernel-firmware using upgradepkg.

1 members found this post helpful.

Ok, thanks. And what about kernel-source?

kernel-source packages live in different folders, given they have different kernel versions, but they collide over the symbolic link /usr/src/linux, which is not a big deal if you just keep that in mind. You should be able to have them side-by-side.

1 members found this post helpful.

Long story short, if you want to maintain multiple kernel packages you'll want to do the following (note: if you're running 32bit Slackware, you may also have smp kernel options... you can installpkg those as well):

installpkg

• kernel-generic
• kernel-huge
• kernel-modules
• kernel-source

upgradepkg

• kernel-headers
• kernel-firmware

Install them so the one you intend to use is installed last (both version and generic vs huge) as this will ensure that any symlinks are set as they should be. It isn't a huge deal if you don't, but generally, the /boot/vmlinuz symlink should point to your normal intended booting kernel, and the /usr/src/linux/ symlink should point to your intended kernel's source directory.

Once you have everything installed/upgraded, create a new initrd (if needed), and update your lilo.conf and run lilo.

1 members found this post helpful.

bassmadrigal and qweasd, thank you for your time and patience.

Your explanations are exhaustive, so, although I cannot do some tests at the moment, I think I can mark this thread as solved.