I'm stoked that the release cycle for 12 was so much quicker than for 11. Great job Pat & friends!

Looking at Changes & Hints, the first upgrade step is a bit vague. So two questions.
1) Is this as simple as
2) I'm running 2.6.17 from 11.x. Do i need to do this first (based on the caveat "if you are running a 2.4 kernel from 11.0)

Thanks

In short, yes

but will it need a reboot after kernel install?

you might also look for any kernel module (2.6.21) package to install. then reboot into that kernel. (edit lilo.conf or grub/menu.lst)

tho' since 2.6 is default now perhaps the modules are included? (explodepkg might be useful there)

huge doesn't need kernel modules

The reason for the 2.6.18+ kernel requirement is that glibc-2.5 requires a 2.6 kernel, and udev requires 2.6.18+.
That being the case, *any* 2.6 kernel will work for the initial upgrade, but *yes* - you do have to reboot so that you're actually running that kernel prior to upgrading the glibc-solibs package.

As to the huge{,smp}.s kernel not requiring modules, that is (mostly) incorrect. It's true that the system will run without them, but you won't have network and other functionality that uses the kernel modules - the only things huge{,smp}.s has that generic{,smp}.s doesn't are filesystem and chipset drivers needed to get a system booted.

for the tips. I'll give it a try later.

thanks for clearing that up rworkman, I'll have to remember that huge isn't HUGE, just huge

I started my upgrade. I installed the 2.6.28 smp kernel and modules without incident and rebooted. everything came up fine. I'm working through the upgrade. Currently on the upgrade everything else step.

IMHO, Pat seemed to rush the upgrade instructions. They are nowhere as thorough as the v11 instructions. For example, in 12 he says For v11 he said
If you are new to upgrading the v12 instructions could be hard to decipher.

Hmmm... perhaps a valid point... If there's anyone to blame for that, though, it's me, not Pat. I'll admit that the CHANGES_AND_HINTS.TXT document (which later became UPGRADE.TXT) was written with the idea that individuals who choose to do an upgrade as opposed to a clean install would be relatively familiar with package management in Slackware. On that note, I happen to think it's a reasonable assumption, but of course, varying opinions are expected :-)

Do I understand correctly that you wrote the UPGRADE.TXT file?

You don't think it possible that a relative noob might have recently installed Slackware 11.0, may not be especially familiar with package management in Slackware, and yet might still want to do an upgrade as opposed to a full re-install?

Most of it, yes.

Yes, I do think it's possible that a new user might have recently installed Slackware 11 and want to upgrade to 12 instead of doing a fresh installation. I also happen to think that it's quite reasonable to expect that user to have learned the basics of Slackware package management first, and if that's not the case, then the user needs to do that prior to considering the upgrade.

Robby - well let me start by thanking you for all the hard work! Slack 12 looks great. I hope you'll accept my criticism in the light it was offered. I have used Slackware since v8.1. I learned Linux using Slackware and have thoroughly enjoyed the journey. I appreciate the effort that Pat, you and others put into it. I hope my comments only help make it better.

Interesting that someone else noticed the same about UPGRADE.TXT for 12. However, I used 11's UPGRADE.TXT to translate 12's. All I have left to move the .new files over the old configs and add the new groups and users to the passwd and groups.

I got quite a surprised after the upgradepkg all, though. I regenerated a new xorg.conf, went into KDE, looked around and exited. A couple of minutes later, I went back into KDE and I'll be darn if it didn't load so fast, it felt like it was just waiting for me to switch back to it. Holly shmokes!!!

Well, as I stated earlier, I *do* think your concerns are valid, even though I happen to think the potential "failure case" is low-probability. That being said, I'll definitely keep this in mind for the next release. In fact, if you notice that the next -current cycle's CHANGES_AND_HINTS.TXT isn't a bit more specific about that portion, drop me an email and remind me.

My two pence worth, and I am familiar with package upgrading that for something as tricky as an upgrade like thse even experienced slackers might need their hand holding. It would have thrown me.