Upgrading Slackware64 Kernel Packages
 

Alright, so I have a question that might sound weird, but allow me to explain.

I have a Slackware64 system (full install) which I've kept current through Dec 19, 2009. The changelog entry for Jan 4th (and the subsequent one on Jan 9th) are a bit more than standard upgrades, as Pat pointed out.

As an experienced Slacker (6+ years) the changes required regarding IDE drives isn't really a big deal, but I decided to go ahead and follow Robbie's howto (he and AlienBob really need to be on the Slackware payroll, IMHO BTW). My root and home partitions are on an IDE hard drive and I have an optical drive and 2nd hard drive on SATA.

It's the first step of the howto that has caused me pause though:

That sounds simple except that day-to-day, I don't run a stock Slackware kernel. I compile and run my own and always have. As I look back on my history with Slackware, I don't think I've ever upgraded kernel packages once I got a system up and running. When there's been big changes (2.4 to 2.6, for example), I've done a full re-install.

Most recently when I made the jump to 64bit, I did a full install using the huge.s kernel and once everything worked, I downloaded the current source from kernel.org and was on my way. I haven't booted huge.s since that day.

I do, of course, know how to upgrade my own custom kernel, but I like having huge.s installed as a backup. If I upgrade gcc/glibc, compile a new custom kernel and update lilo.conf/fstab without upgrading huge.s, then I will be left with only one working kernel.

So, my question is: is it simply a matter of running upgradepkg on the 6 kernel packages (headers, modules, firmware, generic, huge and source)? or is there more to it than that..ie, what about the system maps and symlinks in /boot?

That's about the size of it. upgradepkg or installpkg your new kernel packages and then edit things like /etc/fstab to reflect the new devices names as per Robby's howto.

The system.map and config files and symlinks under /boot aren't actually used for anything (Don't confuse them with /boot/map though, which is part of lilo). I think they're there for debugging/documentation purposes more than anything else.

One thing I do is avoid using the vmlinuz symlink in /boot. Explicitly specifying both kernel and a version tagged initrd in lilo.conf, like such:
It allows for a nice clean backout as you can have multiple versions in your lilo, just incase you cock something up.

Once up and running on the new kernel, you can then removepkg the old ones.

Thank you. Sometimes you just need confirmation from someone else.

I agree regardign the vmlinuz symlink. As long as you edit lilo to point to the correct vmlinuz-2.6.XX file, it shouldn't be a problem. Eliminating the use of it has been on my list of "things to do the next time I fiddle with my kernel" for some time now.

I'm going to mark this one 'Solved' even though I haven't actually done the upgrade yet (things got really busy at work really quickly). Chances are if I end it with a problem, I will have fouled things up so bad as to justify a new thread.