LTP UPGRADE

From: Net Llama! <netllama@linux-sxs.org>

Subject: LTP upgraded to KDE1.92 & 2.4.0-test6 (possible SxS?)
Date: Monday, 21 August 2000 10:44 AM

OK folks, here's the long tale of how i upgraded LTP to the 2.4.0-test6 kernel & then upgraded KDE from the version that came with LTP (20000704) to something a few weeks newer (20000725). I've now got a (mostly) fully functional upgraded LTP system.

Firstly, if you're going to play with the test6 kernel, be forewarned that it requires a newer version of modultils than what comes with LTP (or any previous distro from Caldera). All the package & version requirements can be found in /usr/src/linux/Documentation/changes .

Thankfully, the same ftp site that holds the source tarballs for modutils also has full functional (in LTP/COL) modutils binary RPM's. I grabbed the latest, 2.3.15 and it worked, eventually. Make sure to
take care of this upgrade before even starting the kernel build or you'll end up with a huge mess of ALL the modules for any kernel version on your system. Trust me, i'm speaking from experience. Also,
be forewarned that if you use the RPM to upgrade, and possibly even if you use the source tarball, you may get /etc/modules.conf wiped out, so make a backup copy in advance. Also, thanks to Jeff Hawkins' help, we've determined that this new version of modutils parses /etc/modules.conf differently from any previous version. I'll quote Jeff's comments, since they make far more sense than my own version:

"I have isolated the reasons for the "/bin/echo" and "not ELF File" errors produced by the new DEPMOD. The errors are due to the PATH statements in the "modules.conf" file provided by Caldera. They are simply INCORRECT. The "/bin/echo" error is being produced by the line: path[usb]=/lib/modules/`uname -r`/`uname -v`

The new DEPMOD is choking on the "uname -v". Looking at the source code, the logic falls into the catch-all area which tries to use "/bin/echo" as a last resort. To me this is a bug in DEPMOD (in it's
config.c utility module). The catch-all logic doesn't make sense because it tries to open the "/bin/echo" as a file/directory...

Anyway, you can completely remove the USB Path Statements from the Caldera provided "modules.conf", since DEPMOD already has the correct paths as part of it's DEFAULTs. Reference the "man" page for "modules.conf"."

No serious problems in 'make xconfig', or surprises, but then again this was my first trip into 2.4.0-test land so i had nothing to compare to. Stay away from anything marked EXPERIMENTAL unless you really know what you're doing. I didn't even touch the devfs stuff. Apparently a
new feature of 'make modules_install' is to incorporate running 'depmod -a' at the end, as to make all the newly created modules dependent on the new kernel.

Also, as of this test6 kernel, the directory structure for the modules in /lib/modules/2.4.0-test6 has changed drastically from all previous kernels from all the 2.2.x, 2.3.x & 2.4.x trees. The modules now are split into 3 major categories (directories) of arch, drivers & fs. They are then further subdivided (subdirectories) from there.

Using this new kernel definitely provided a noticable performance boost on my PII-400 system (128MB RAM) over the default LTP kernel which i found to be quite sluggish.

Next, onto upgrading KDE. Up until the upgrade, i found the default KDE2 (beta) system that came with LTP to be unbelievably slow & buggy. I honestly didn't even consider it usable as various parts crashed quite often, and starting or stopping anything took 3 to 4 times longer than in KDE-1.1.2. I was hoping that a newer version of KDE2 (beta) would possible have some of the numerous bugs hammered out, and thankfully it does!

I really wasn't at all in the mood to start playing with the latest snapshot. I wanted prebuilt RPM's designed specifically for Caldera. Thankfully I found a bunch built for COL2.4 that were about 3 weeks newer than those that came with LTP, so that was improvement enough for me. I got all the RPM's here:

ftp://ftp.kde.org/pub/kde/unstable/distribution/2.0Beta3/rpm/Caldera-2.4/RPMS/

I'd recommend mirroring the directory structure from the server on your HD when you download the various categories, as to make it easier during the actual upgrade process. FOr example, on the server there's a kdebase directory with all of the distinct packages that make up the traditional kdebase package. I created a kdebase directory, and then downloaded all of those packges into it.

The only keys to getting everything upgraded properly as far as i could tell is:

1) Run all the upgrades in runlevel 3 (console mode). Do NOT leave KDE (any version) running while you upgrade or you may have very strange results.
2) Upgrade kdelibs packages first
3) Upgrade kdesupport packages next
4) Make copious usage of the --force and --nodeps switches if you get errors complaining about various things.
5) Upgrade all the other categories in any order, it shouldn't make a difference.

Once this is done, either reboot or run 'telinit 5' to restart X & KDE. You should be able to log into KDE2 without any problems whatsoever.

For me, the performance improvements with the newer kernel & KDE2 were incredible. Both memory usage & system load have dropped significantly. KDE2 runs at least 50% faster than with the default LTP packages.

There are a few minor problems that i'm now encountering, however. kpackage seems to be broken somehow, with ld.so errors. Also, KWrite no longer works. Those are the only problems that i've found thus far, and i haven't really made any attempts to fix them yet, so they may be easily fixable with a little effort.