Composed by Myles Green <firstname.lastname@example.org>
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
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 install.man
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 ) :
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
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 ftp.kde.org.
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
# 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 system.map to /system.map, moves the old ones to /vmlinuz-old and /system.map-old 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 :)