I need to move from 3.10.17 to 4.1.6. I have already updated slackpkg. "slackpkg search kernel" returns this:

[ upgrade ] - kernel-firmware-20131008git-noarch-1 --> kernel-firmware-20150820git-noarch-1
[ upgrade ] - kernel-generic-3.10.17-i486-3 --> kernel-generic-4.1.6-i586-1
[ upgrade ] - kernel-generic-smp-3.10.17_smp-i686-3 --> kernel-generic-smp-4.1.6_smp-i686-1
[ upgrade ] - kernel-huge-3.10.17-i486-3 --> kernel-huge-4.1.6-i586-1
[ upgrade ] - kernel-huge-smp-3.10.17_smp-i686-3 --> kernel-huge-smp-4.1.6_smp-i686-1
[ upgrade ] - kernel-modules-3.10.17-i486-3 --> kernel-modules-4.1.6-i586-1
[ upgrade ] - kernel-modules-smp-3.10.17_smp-i686-3 --> kernel-modules-smp-4.1.6_smp-i686-1
[ upgrade ] - kernel-headers-3.10.17_smp-x86-3 --> kernel-headers-4.1.6_smp-x86-1
[ upgrade ] - kernel-source-3.10.17_smp-noarch-3 --> kernel-source-4.1.6_smp-noarch-1

My plan is to installpkg kernel-generic and kernel-modules, then make a new ramdisk and lilo entry, then update the rest of my packages. Is that the right decision?

Indeed you should never "upgradepkg" your kernel-generic kernel-huge and kernel-modules packages, but rather use "installpkg" so that you have both the old (working!) and the new kernel packages installed in parallel.

Then you can upgrade all the rest of the packages (don't forget to also install packages that were added to your particular Slackware release by running "slackpkg install-new") and after that, generate the new ramdisk (initramfs to be precise).

If you create the ramdisk before upgrading all packages, the ramdisk may contain outdated software and no guarantees can be made that it will allow your computer to boot.

1 members found this post helpful.

Thanks, AlienBob. Honored to encounter you.

As you can see, the first post now says "install" instead of "upgrade". I edited it before reading your reply, because I read this guide, which, ironically, you wrote.

I still think it's sadistic to leave the kernel modules etc. unblacklisted by default.

Can I assume that "slackpkg upgrade-all" will now be safe and all newly installed packages will work correctly with the old kernel, provided I have blacklisted the kernel-related packages?

before
you should issue a
when moving to a new version, to avoid breaking things that need the added packages in the new version.

That's true, I figured it was implied by Eric's quote. So I'm going to:

1 members found this post helpful.

Now, what about "kernel-firmware-20131008git-noarch-1"?

When should I upgrade it?

New package versions may indeed depend on the new kernel, so I'd be inclined to do a 2 phase update.

Parallel install the new kernel and modules along side your existing ones.
Build a new initrd for it (using the -o option on mkinitrd so as not to clobber the old one)
Add the new entries to lilo and reboot into the new kernel.
Once in the new kernel do install-new, upgrade-all, then rebuild the new initrd to pick up the updated library and utility versions (remembering to refresh lilo).
Reboot again.

Finally cleanup any leftovers (such as removed packages, the old kernel and initrds) and then rebuild and reinstall any of your 3rd party stuff from places such as SBo.

I don't think it matters when you do firmware, leaving it to the upgrade-all is probably fine.

There will always be edge cases, which I guess is why UPGRADE.TXT occasionally give additional instructions, but as a general guide, I think the above is about right.

1 members found this post helpful.

I hesitate to mention this, as it can be two-edged sword (offering to delete anything that is not part of official Slackware and that has not been blacklisted), but 'slackpkg clean-sytem' can help with this.

Maybe I'm just becoming a Luddite but gosh! guys that seems like an awful lot of work "maintaining the maintainer". Do many of you find that upgrades are necessary often to keep doing what you use a computer for?

No, it's Slackware. Funny thing, this afternoon I had to fix a client's desktop machine running Ubuntu 14.04 LTS. The system wouldn't boot anymore. After quite a bit of searching, I found out that a year and a half of updates had filled the /boot partition with a few dozen kernels and initrd images, after which dpkg was left in a broken state, because the last initrd couldn't be built anymore due to a full partition. I managed to boot the system, but when I wanted to remove a handful of obsolete kernels, aptitude informed me that in order to remove them, I had to install the most recent one first. Duh! It took me more than half an hour of jumping through burning loops using dpkg --remove --purge and apt-get -f install to have a usable system again. I'll take Slackware anytime, where you get to choose if you want to use installpkg or upgradepkg.

2 members found this post helpful.

This sort of upgrade is not something I do frequently. On production machines, barring any major security concerns, I rarely upgrade a kernel (now that low latency is basically default). As long as the one I'm on is working as expected, I don't usually touch it.

So, no.

I normally upgrade packages first. I cannot recall ever having issues doing this.

I always have at least two kernels installed on my systems (all x86_64, all -current). One is the "in use" kernel, the other is the "working" or fall back kernel. I have two lilo boot options, Slackware64 and Working.

The kernel is normally blacklisted. After using slackpkg to install-new, upgrade-all, clean-system as applicable. I comment out the kernel related lines (except for huge) in blacklist and do a "slackpkg download kernel". I then install each of the kernel packages using installpkg. This action installs the new generic kernel as the default (huge is blacklisted). (I probably could use "slackpkg install kernel" but prefer not to.)

I now have three kernels installed at this point. Using for the example, 4.1.6, 3.18.11 and 3.14.33. Before the upgrade Slackware64 boot to 3.18.11 and Working boot to 3.14.33, now Slackware64 boots to 4.1.6 but working still boots to 3.14.33. I change the "working" kernel 3.14.33 symlinks in /boot to point to 3.18.11. So now new kernel 4.1.6 is set to boot via "Slackware64" and kernel 3.18.11 set to boot via "Working" and kernel 3.14.33 simply taking up space.

The next step is to setup the ramdisk. Since I use a mkinitrd.conf file on each machine I issue the following commands:

mkinitrd -F -k 4.1.6
mkinitrd -F -k 3.18.11 -o initrd-working.gz -s initrd-working-tree

Of course at this point I need to run lilo to set it all up to work. No need to edit lilo.conf, it is setup for this.

Then reboot.

Should the new kernel not work, I can always fall back to the previous kernel. Once I am satisfied that all is well I remove kernel 3.14.33.

I have two other steps in my setup. Normally I run "sh NVIDIA-Linux-x86_64-352.55.run -k 4.1.6" before rebooting. After the reboot I run "/etc/rc.d/rc.vboxdrv setup" to recompile their respective kernel modules.

I finished everything, so I'm going to mark this question as solved. There's only one thing you guys forgot to remind me to do:
I'd also like to raise one problem I encountered. Being in rural Africa, I had slow and choppy internet access. While running "slackpkg upgrade-all", my internet cut out. I walked in on my computer installing packages about 24 hours before I expected it to be finished downloading, and I knew I was going to have trouble. Sure enough, gawk depended on a library that hadn't been installed yet, and slackpkg depended on gawk. So I had to download that library on a different computer.

Wouldn't it be nice if slackpkg accepted arguments similar to tagfile categories? It would be nice if I could upgrade the required packages first. I fantasized earlier about a world where I could do something like this:

From /etc/slackpkg/slackpkg.conf:PS Assuming that the library in question was libmpfr (just a guess) you could have done
slackpkg update
slackpkg upgrade mpfr
slackpkg upgrade-all

But I am not sure to understand the issue. Do you mean that you tried to upgrade gawk before upgrading mpfr?