Yesterday for the first time I experimented with updating Slackware. I am updating from version 10.0x to 10.2x using some testing partitions rather than my "clean" partitions.

As forewarned in another thread, the update process deleted my 2.4.28 kernel source files. The update also monkeyed with my 2.4.28 modules.

Thus, I still can boot with my with the 2.4.28 kernel, but I receive several messages about "can't locate module xyz."

So I copied /usr/src/linux-2.4.28 back to my testing partitions. I recreated a link from /lib/modules.2.4.28/build to /usr/src/linux-2.4.28.

I then rebooted with the 2.4.28 kernel, ignoring the module-related boot error messages, and after logging in as root I tried running depmod -a. No luck. I received a bunch of "cannot read ELF header" and "xyz is not an ELF file" messages.

During any updating process like this, I tend to be conservative. I want to maintain my 2.4.28 kernel until I am satisfied that I have compiled the 2.4.31 kernel to my liking as I previously did with 2.4.28. Therefore, I basically need to maintain two versions of the kernel concurrently for a while.

Configuring my GRUB menu list to support more than one version of a kernel is easy and already done, but I'm confused about how to maintain two kernels otherwise. I'd appreciate some guidance.

Additionally, how does one avoid this problem with future updates? A significant presumption in PV's UPDATE.TXT is that one is not going to maintain a previous kernel. Does one have to use installpkg to install the new kernel sources, headers and libraries and then later proceed with upgradepkg */*.tgz?

Thanks again.

"During any updating process like this, I tend to be conservative. I want to maintain my 2.4.28 kernel until I am satisfied that I have compiled the 2.4.31 kernel to my liking as I previously did with 2.4.28. Therefore, I basically need to maintain two versions of the kernel concurrently for a while.

Configuring my GRUB menu list to support more than one version of a kernel is easy and already done, but I'm confused about how to maintain two kernels otherwise. I'd appreciate some guidance."

You need to keep two versions of the kernel, initrd (if you are using initrd), and /lib/modules/(kernel version number). You have to tell grub to keep the kernels and initrds seperate. The kernel knows that the /lib/modules/ directory with the kernel's name is where its modules are kept.

"Additionally, how does one avoid this problem with future updates? A significant presumption in PV's UPDATE.TXT is that one is not going to maintain a previous kernel."

I suggest that you set up your own kernel compile procedure to your taste. Here is a howto on compiling the kernel.

http://www.jasensky.com/howtos/basickernel.html

---------------------
Steve Stites

Maintaining two kernels is fairly straightforward, but does require some manual work to handle it properly. Essentially though, it comes down to retaining both copies of the kernels in the /boot directory, as well as referencing two different kernels in your boot loader (ie, lilo or GRUB) Below is what I've done to "dual boot" between two different kernels; I expect others would have other suggestions

First let's assume that you're using lilo and that your existing kernel entry looks similar to the following (I'm using /etc/lilo.conf in these examples)
Now, "vmlinuz" is a softlink to the actual kernel, which may be named something like "vmlinuz-2.4.28", and naturally, it can only point to one kernel at a time. Therefore rather than to use a generic link to reference the kernel, what I do is copy the actual kernel (ie vmlinuz-2.4.28) under a different name, for example
Next edit and update your bootloader as needed to use this (renamed) kernel. Change the label while you're at it, and if you're using lilo, rerun /sbin/lilo and reboot so the changes take effect. The purpose of this exercise is just to make sure that things are working OK at this stage. To illustrate, after applying the above changes you'd end with something like:
Assuming that you are installing a newer kernel, you basically just need to repeat the above steps once the recompilation has been completed: copy the new kernel ("vmlinuz") to a new name (eg "kernel-2.6.x" or similar), then replicate the lines in lilo to refer to the new kernel. Again, for lilo you will need to run /sbin/lilo, then reboot and you should be able to choose between the old and new kernel
To summarize, you just need to refer to each kernel discretely, and of course, each time you install a new kernel, you'll need to manually rename it and then update your bootloader to include it. If my memory serves, that ought to cover the key points. Good luck with it

What modules are missing. That sounds like you upgraded at least one package that contained kernel modules. Maybe alsa. You could re-load those packages, or re-compile the modules from the 2.4.28 sources, using your "saved" .config.

I'll admit that I didn't try to keep my existing kernel/soruce when I went from 10.1 to 10.2. But, I do keep both a 2.4 and a 2.6 kernel on the same system. lilo keeps track of the kernels, and I changed rc.S to use rc.modules-`uname -r` instead of having to flip the soft link betwwen versions.

Cheers,
Eddie

i do what J.W. does, and i find it to be a very good method for keeping everything straight, as well as for ease of adding kernels to lilo. after building the kernel, i just cp the bzImage to /boot/vmlinuz-2.6.x and keep them all there. then as J.W. outlined, all you have to do is copy an existing lilo entry, putting it above/beneath the one you copied, and change the kernel number and label. then run lilo and you're in business.

Gosh, J.W.! You spent so much time explaining the one part I got an easy handle on! I use GRUB, BTW, and one of the first things I learned 3 years ago when I began dinking with this stuff was to configure GRUB such that any kernel update would not clobber my existing kernels.

FWIW, I never use the soft link vmlinuz. I always edit my GRUB menu.lst to use the actual file and not the soft link. That is how I avoid problems when updating because typically updates reassign the soft link, and PV is no exception---he did the same thing. But thanks for the explanation because I'm sure future viewers of this thread will need this information you shared!

What is bothering me is that when updating the entire distro, the existing kernel sources and modules get clobbered. How do I perform the actual update to avoid that? I expect to eventually use the newer kernel supplied with a newer distro, but there is that transitional phase where I want my previous kernel in standby. If I have learned anything from using computers the past 20+ years is that updating sometimes go snaky.

In another thread somebody hinted that before I perform the upgradepkg */*.tgz I should first manually perform an installpkg of the new kernel-headers-2.x.x, kernel-modules-2.x.x, and kernel-source-2.x.x, (alsa too? I don't know). After completing that then do the massive upgradepkg */*.tgz to update the entire system. I was going to wipe my testing partitions and try again with this approach, but I haven't gotten that far yet (things to do, places to go, people to see, etc., etc.).

Yes, I performed a massive upgradepkg */*.tgz as suggested in the UPDATE.TXT guide, which included the newer alsa and 2.4.31 kernel stuff. When I was finished updating all packages, the 2.4.28 kernel sources were gone, the /usr/src/linux soft link reassigned to linux-2.4.31, and my 2.4.28 modules got clobbered. Thankfully I'm careful with backups before I attempt projects like this and I easily restored both (which eliminated the messages I saw earlier).

As I write this I'm using my old 2.4.28 kernel .config file to run a pass at recompiling the 2.4.31 kernel. We'll see how that goes. But my primary focus for this thread is how to methodically add the new kernel and modules in an update release while preserving the previous kernel sources and modules. I've already learned that upgradepkg */*.tgz won't suffice. I hope to try the idea above, but I'm open to anything else all of you have to share.

I assumed you downloaded the newer kernel from Kernel.org to /usr/src, unpacked it, and then repointed /usr/src/linux (which is a softlink) to the new kernel directory. After that it would be a standard kernel recompile (as outlined in either of the stickies by DaOne here in the Slack forum).

Personally I would not use upgradepkg to do upgrade the kernel - I'd recommend doing it manually, not only for the educational experience but also because you get much better visibility into what is actually happening within the process. Have you tried it that way, and if not, why not give the 2.6.x kernel a shot. Let me know how it goes

And the problem there is that your old system and new ones use a different kernel version. So, any package, thats newer, that touches any part of the kerenel, it's modules, and other dependencies will be upgraded.

The UPGRADE.TXT method works perfectly, as long as you understand this point, and sort out any .new config files.

My suggestion would be to save off your current .config. Run the UPGRADE.TXT, boot from the new "vanilla" kernel that comes as part of that, and then rebuild your "custom" kernel based by using your saved .config as input to make oldconfig. ( I think that's the option).

Cheers,

After two days of experimenting and playing with the updating process I now can say that I agree!

After the past two days I have more or less concluded the same. I have no issue with temporarily using the newer "vanilla" kernel. I merely want a backup path to a known working kernel in case the updating process flies south. There is a reason why a particular bumper sticker remains popular!

As far as recompiling, I intend to do that as well. An old box, so recompiling will take a while, but doable. After learning the pitfalls of updating, my previous recompiled 2.4.28 kernel still boots just fine and my 2.4.28 modules are restored and safe. Through brute force and two days of experimenting I think I have answered my original question of this thread.

I have made several practice runs at this updating thing and as a result I wrote a detailed how-to that surpasses the almost non-informational UPDATE.TXT. The how-to will get posted to my web site whenever I finally get around to building the site (soon I hope---if I can finish installing 10.2!). There are several places where things break during updating that easily frustrate the non-veteran, but my how-to documents most of those caveats. I now see why updating receives a lot of queries here at LQ.

My current puzzle is that nothing I do gets KDE to play sounds. ALSA (1.09a) is installed correctly, there are no error messages anywhere, aplay works fine in X and non-X, but KDE refuses to play anything. I've tried different sound settings in the Control Center. Nada. lsmod shows a lot of sound modules loaded so I'm reasonably certain ALSA is loading correctly. However, I don't think artsd is loading correctly because in my production partitions there are two artsd processes in the process tree from kdeinit and in my 10.2 testing partitions there is only one artsd. My next move is to uninstall 1.09a and return to 1.07 and possibly the 2.4.28 kernel. Of course, sound in KDE works just fine in my production partitions. But sadly, I now see why sound is another popular issue here at LQ.

FWIW, I have not yet updated KDE from 3.3.2 to 3.4.2 (as is packaged with 10.2), but I don't see why that should make a difference. After all, PV compiles KDE straight from the box and does not do anything extra.

I've been surfing for a while trying to shed light on this. I have no .asound or /etc/asound.conf config files and the ALSA site says those files are not needed.

I'm not a sound guru or music buff so I don't play with sound at all. I merely enjoy a few simple system sounds. I'm grateful to anybody with ideas on what to check next to get KDE to play sounds. Otherwise I'm now reasonably comfortable with how to update Slack.

I found that even though no hardware, or configuration files, changed during my upgrade, I still had to re-run alsaconf to get my sound to work.

Cheers,
Eddie

The problem is not ALSA, but KDE. ALSA worked fine after the update. KDE refused to play the sounds.

Regardless, I resolved the problem by updating KDE too, from 3.3.2 to 3.4.3. KDE again plays sound. I don't understand why I had to update KDE, however.