Well isn't that typical - no sooner had I installed the
operating system than my mind is thinking about upgrades already!
My first task was to find out something about the
packages installed on my system.
NOTE: These notes are now quite old, and somewhat
specific to Red Hat 5.2. Red Hat has since re-organised their products
into Red Hat Enterprise Linux (RHEL) and Fedora Core (geared to
developers and early adopters). For more details check out Red Hat.
RPM packages
Red Hat and other versions of Linux use a package format
known as RPM. This is to allow files to be installed and managed as
complete packages. RPM packages are files with the suffix ".rpm" which
contain the files which make up the package as well as information
about the package (such as description, version, and related packages).
The command "man rpm" gives a good outline of the
commands available for package control.
Section 9 of the Red Hat installation guide describes
the background to RPM, as well as giving good examples of how to use
it. For those who don't have the guide, check out http://www.rpm.org for up to date RPM
documentation.
Section 10 describes a graphical tool known as "glint",
which is a front end to the RPM system. Just run "glint &" to start
it.
I was interested in solving problems using a combination
of glint and rpm. You may recall that I mounted the Red Hat CD in
directory /mnt/cdrom. I used the "available" button in glint to display
a navigable tree of packages. I discovered that this finds and displays
details of all uninstalled ".rpm" files on the system - including those
on the CD! So, I quickly found two which were not installed:
kernel-source-2.0.36-0.7.i386.rpm
kernel-ibcs-2.0.36-0.7.i386.rpm
I then found a whole series of packages in
/mnt/cdrom/RedHat/RPMS, including these:
kernel-2.0.36-0.7.i386.rpm
kernel-headers-2.0.36-0.7.i386.rpm kernel-ibcs-2.0.36-0.7.i386.rpm
kernel-pcmcia-cs-2.0.36-0.7.i386.rpm kernel-source-2.0.36-0.7.i386.rpm
kernelcfg-0.5-3.i386.rpm
I then used the command "rpm -qa | grep kernel" to show
installed packages with "kernel" in the name. This was exactly the list
shown above, minus the two packages glint said were available.
So, a combination of a graphical program with a good
old-fashioned command line session quickly gave me a good idea what was
(or was not) installed on my system.
You might wonder why I was looking at these files in
particular - read on.
Installing new kernels
I noted from the magazine that the Linux 2.2.2 kernel
was not included in the Red Hat Linux 5.2 distribution from PC Plus
(May 1999). After some delay, I decided to try to install it.
I had already looked far enough ahead to section 11.6 of
the Red Hat Installation Manual on the CD
(doc/rhmanual/manual/index.htm) so I knew that the file /etc/lilo.conf
is used by the Linux boot procedure to select a kernel to run. I
expected to copy the Linux 2.2.2 kernel from the CD, edit the file, and
reboot with the new kernel. Things turned out to be a little more
complicated than that.
I decided to duplicate the relevant 4 lines in
lilo.conf, changing only the label - from linux to l22.
I expected to be able to select l22 to start the
current 2.0.36 kernel. The prompt only came up with linux
(oh, and dos of course!) Perhaps LILO realised the
kernel was unaltered in the new entry ? I later realised I had just
failed to run lilo.
I quickly looked in the directory /boot, and discovered
not only the kernel, but several other version and info files bearing
the suffix 2.0.36. Would the new kernel be accompanied by these files
as well ? There was only one way to find out.
I quickly found the linux directory on the second May
1999 CD. It contained files linux-2.2.2.tar.gz and
linux-2.2.2.tar.gz.sign, and a directory min_reqs. The first file was
shown as a WinZip file. Having spent good money on WinZip, I decided to
try to extract the contents. First I copied all the files to C:\Linux.
After extracting, the directory linux-2.2.2 had
appeared, and it contained the file linux-2.2.2.tar, which to my
surprise was also shown as a WinZip file! I had expected a UNIX-style
tar file, but didn't realise WinZip could decipher it. I tried WinZip
again - and it did indeed extract the contents of the file into a linux
directory containing a whole series of sub-directories, some of which
contained source files and makefiles. Suddenly the thought struck me
that I might have to build the kernel myself.
At this point I hesitated - in fact, I did nothing for
several months! When I returned to the subject, I decided to install
the kernel-source-2.0.36-0.7.i386.rpm package mentioned under "RPM
Packages" above. This created kernel source directories in
/usr/src/linux-2.0.36. I now refered to the Linux Advanced Workshop in
PC Plus (also May 1999 - a bumper edition, that!) which lists commands
in the order needed to build a Linux kernel from the source tree. I
compared these with the README file in the kernel source tree and saw
no real differences (fortunately). The kernel build went smoothly.
Though the README mentions copying the newly built kernel over the
current one, I discovered that the example lilo.conf file in PC Plus
was a better example. You can just refer to the zImage file in the
source tree directly. The only slightly worrying moment was running
/sbin/lilo to re-install lilo in the boot sector. I hoped this would
not mess with my Windows partition (/dev/hda1). Relax. I ran lilo with
-t and -v options first and it claimed it would be updating /dev/hda3.
And it did.
I then turned my attention to the Linux 2.2.2 source
tree extracted earlier. I tried to build this in the same way. I
immediately ran into a problem - the files I extracted with WinZip were
in DOS format! I resorted to using "tar xvf" to extract the files under
Linux. I found it necessary to create the userid 1046 who owned the
files in the tar file.
When building the 2.2.2 kernel, I had to use bzImage
rather than zImage, which according to the documentation means I built
one huge kernel. Now the fun really began.
I found that the system would boot with the 2.2.2
kernel, but I could not mount the Windows file system. I discovered
when running xconfig that some necessary options were not set. I set
the "m" option for the file system modules including VFAT, to match my
previous 2.0.36 configuration.
When I rebooted, still no Windows files. I now looked in
/var/log/messages and discovered the error message "Cannot load map
file". I got round this by copying the file System.map to
/boot/System.map-2.2.2 and making System.map a symlink to it. Now I saw
a different problem - the message "No module symbols loaded". I never
found the real reason for this. I discovered modules.txt in the
Documentation directory, which mentions /sbin/depmod and
/sbin/modprobe. I then ran the command "modprobe vfat.o" rather
optimistically and to my surprise I could now mount /dev/hda1. Don't
ask me why.
Finally I decided to rebuild the kernel with theVFAT
module linked in at build time rather than dynamically at run-time.
This also worked, and at last I had succeeded in a Linux kernel upgrade.
|