Linux Step By Steps
LTP upgrade to KDE2.1 & 2.4.2 kernel

Composed by Myles Green <>

Please read and enjoy ( or not... ) my saga of the road I took upgrading the various parts of LTP. This isn't everything necessary, I'm sure of that, but it's what I've managed to do thus far. The best
part is I didn't even break anything this time. Well, there's Kpackage but I don't know that that wasn't broken right from the start, I wouldn't because I've not used it in almost 2 years.

So, here it is:
Installing and upgrading Caldera's "Linux Technology Preview" release.
More than one way to skin a cat.

I have, in my computer, a 15 GB Maxtor UDMA 66 drive that currently is connected to IDE1 on my motherboard ( GigaByte GA-5AA, BAT ) rather than my Promise ATA-100 card for reasons which I won't go into right now.

Installing LTP was pretty much straight forward: I had approximately 4.2 GB available near the end of the drive and that's where it went,lock stock and barrel, all in one partition. I wanted to share my /home partition with another distro ( Slackware-current ) and knew that there were going to be some problems involved in doing this.

For one thing, Caldera starts numbering user UIDs at 500 whereas Slackware starts at 1001. For another, the default groups are different: Under Caldera I am username "mylesg" and belong (by default) to the group "users", whereas under Slackware I am username mylesg and belong to the group "mylesg".

I overcame this by editing the users ( as root, using COAS -> System -> Accounts ) and deleted the user "mylesg", then under  Options -> Preferences, I changed "Mimum UID" from 500 to 1001 and "Group Assignment Policy" from "Default Group" to "User Private Group" via the handy drop-down box. After doing this, I recreated the user mylesg but when I tried to add mylesg to other groups it failed to write them. I overcame this by using mcedit ( part of Mindnight Commander ) to edit the file ( as root ) /etc/group and adding mylesg to the appropriate groups and then saving and exiting from the editor. Next, I added an entry for my /home directory into /etc/fstab temporarily point to /mnt and mounted it. I then copied the FTP, HTTP and SAMBA directories from /home into /mnt and then deleted the /home/mylesg directory ( remember, I want to use my old directory not the new one ) leaving /home empty.
Next, I unmounted /mnt and changed /etc/fstab to mount that partition on /home instead of /mnt at bootup and remounted it. As I was logged in as root, I needed to logout and login as mylesg: success! All files were readable and writable. Next!!

At this point I should tell you that before I did any of the above I install Midnight Commander - a file manager and editor similar to Norton commander - as I can't stand using either Vi or Emacs. It's a personal preference and if the distro I'm using doesn't have it, I install it first thing.

The next thing I did was to get and install the source to XF86-4.0.2 into /usr/local/src:

# cd /usr/local/src
# tar zxvf <path to file>/X402src-1.tgz
# tar zxvf <path to file>/X402src-2.tgz
# tar zxvf <path to file>/X402src-3.tgz

That will leave you with a directory /usr/local/src/xc/

# cd xc
# make World && make install && make

That starts the build and installation process, if you have some chores awaiting you around the house  now would be a good time to get at them, you'll have the time ;)

After that process finished, I ran ( as root ) :

# xf86cfg

This starts a nice graphical utility that sets up and configures X automagically for you, leaving you looking at a diagram-like represtation of your system - mouse, keyboard, video card, monitor and
CPU tower. You can, of course, also change these settings by clicking on any one of the representations.

Should the above utility not work for you, there is also the old standby commandline config tool "xf86config". I used them both and they both produced usable configurations on my system.

Next, I add a few bits of software that I like to have on my systems:
Gnupg, Gftp and CompuPic. You of course can add whatever you like.  These are, once again, personal preferences.

Adding an upgraded KDE2 to LTP proved to be somewhat tricky, it's not as straight forward as it could be. The reason for this is that LTP comes with a pre-release version of KDE2 that is installed along side of KDE1.1.2 allowing you to access either one.

The route I settled upon after some trial and error was, and I'm certaily not touting this as "the" way to do this:

Grab and install all the binary packages for KDE-2.0 from the Caldera updates to eDeskto 2.4, followed by the binary packages to KDE-2.0.1 and KDE-2.1 from

Are you shaking your head right about now? I did, right after I came up with the idea. Consider this: compiling version 2.1 from source resulted in messed up menu's amongst other problems and resulted in something that was, by comparison, something of a disaster.

Were I to go this route again, I would lilely use SRPM's and build them to my system though I seem to recall trying that at one time. I don't remember the specifics but IIRC they wouldn't build.

As they say, the proof is in the pudding. Presently, I have no dupicates in my menus and everything that's supposed to be there is there and working. Everything that is except for Kpackage and I saw a post recently where that problem was addressed so I'll be looking into
that and correcting it.

Upgrading the kernel was the part I was looking forward to and that was next. In preparation, I grabbed the SRPM of modutils-2.4.3 and rebuilt and installed it. Then I grabbed the source to the current ( as of this writing ) kernel, removed the symlink ( linux ) to the old kernel ( linux-2.4.0 ) in /usr/src and unpacked it:

# cd /usr/src
# tar zxvf <path to file>/linux-2.4.2.tar.gz

This leaves you with a directory named linux which you should rename to
linux-2.4.2 ( if that's the kernel version you used ) and then recreate
the symlink:

# mv linux linux-2.4.2
# ln -s linux-2.4.2 linux

Next I configured and built the kernel, if you don't know how to do this please see the section on Recompiles on the Step by Step site for complete directions.

When building my modules it was discovered that the version of modutiles I used depended on LILO being installed and useable, it wasn't. The LTP release uses, as does eDesktop 2.4, GRUB as the bootloader by default and installs a version of LILO ( 21.0 ) that does not recognise drives larger than 1024 cylinders and mine has over 1600.  We have a problem Houston.

I got the source to LILO-21.7 and untarred it into /usr/local/src, read the README file and decided upon the QuickInst method. I first edited /etc/lilo.conf to reflect my system and then tried to build and install LILO. By this time it was getting late and I couldn't see the problem but LILO would not build. Frustrated, I went to bed as it was already quite late and it had been a long day thus far from clean installation to this point.

The next morning, while sipping my morning cup of java ( well the first of 3 really ) I spied an email citing the very problem with LILO that I had been having the night before. I piped in adding my two cents worth and then started thinking - isn't that always the way? Open your mouth first and *then* start thinking.

Back to the source! Using my trusty MC I started poking around and finally noticed that there was yet another readme file in there. This one was README.common.problems. Without scrolling one line the answer was right there: update bin86. There was even a link pointing to the source for it. So I grabbed that and went to fill my coffee cup.

After building and installing bin86 I rebooted. I dunno why, it just seemed to be The Right Thing(tm) to do. After that the installation of LILO went without incident and so too did the building and installing of the kernel modules which, by the way, also installs your new kernel image to /vmlinuz and your to /, moves the old ones to /vmlinuz-old and / and reruns LILO for you. If you have your lilo.conf set up correctly to point to "linux" and "linux-old" ( in addition to any other OS's ) you will always have a copy of your old ( but working ) kernel around in case you blow a configuration.

Oh, and yes the system boots up again. One is presented with a nice looking menu, white text on a red background, with your choices of boot selection. The cursor ( arrow ) keys are used to select your choice and the enter key sends you on your way. Now for that last cup of coffee.

Anyway, that's how I did it. It may not be The Best Way(tm) but hey, It Works For Me!(tm) and it kept me out of trouble for a day and a half :)