Email Brian
Brian's Website
Email Tom
Tom's Website
|
Email Brian Brian's Website |
|
Email Tom Tom's Website |
Go to the Table Of Contents
Did you read the Preface? Thanks!
Always make a full system backup before doing any kind of major system update. The safety net a backup provides is worth far more than the time it takes, and this is doubly true when upgrading a Linux installation. Nine times out of ten, the upgrade works as advertised, but keep in mind that an unrecoverable error or event is only unrecoverable if you do not have a backup.
In addition to a restorable system backup, ensure that you also have separate copies of any software packages that you have downloaded, installed, and want to keep. This is especially true of software built from source. Compiled executables will not necessarily link properly with the newer system libraries, which are typically part of a system update. See the "Recovering from an Upgrade" section later in this chapter for more details on these challenges.
The concept of an upgrade implies that you already use an earlier version of Caldera OpenLinux (COL). If this isn't true, then STOP! This chapter is not for you. Explicitly, Caldera's update routine is effective only for transitioning OpenLinux 2.2 or 2.3 to the version on your new Installation CD-ROM.
This process does not upgrade any other distributions, such as Slackware, Corel, Red Hat, Debian, Mandrake, Yellow Dog ... (yes, the list goes on and on, so we'll stop). Some of those distributions offer their own versions of an upgrade script. Others, such as Debian, ship with tools that allow the user to upgrade a distribution directly over an Internet connection.
The primary reason for performing an upgrade - as opposed to starting with a fresh install - is to preserve a system's existing configuration. This is especially true in situations where a prior version was installed on one large partition, thus making it difficult to separate out data and programs from the version-specific distribution software.
The difficult task for the authors of an upgrade script is to cope with a relatively unknown environment (any running OpenLinux System) and coherently make it as much like a fresh install of new software as possible. All this must be accomplished without overwriting existing data, programs compiled to specific libraries, or custom configuration scripts. If all this sounds a bit tricky, that's because it is. Even when upgrading a fresh installation of COL version 2.2, we found that parts of the system (software, not hardware) were in need of further attention following the update.
In the more common scenario of an installation that's been patched, here and there, piecemeal over time, we have grave doubts regarding the updater's ability to deliver a fully functional system. We are always open to pleasant surprises, though.
In order to understand the activities of the /sbin/upgrade.col program, it's important to first grasp how software is typically installed and maintained on an OpenLinux system. The basis of software package management on Caldera distributions is the Red Hat Package Manager (RPM) program. This is a tool and a packaging format written by Red Hat, and subsequently licensed under the GPL. It is a command line tool for adding, deleting, updating, and querying software packages installed on your system.
Note
There are four distinct ways to view RPM. First and foremost, it is a package management system. Additionally, it is a package format, a package management database, and a tool for accessing the database and installing the packages. When we refer to "rpm" (emphasizing the lowercase aspect), then most often we're referring to the tool that is executed from the command line.
RPM packages generally have long filenames that encompass the name, version information, and more. For example, the file XFree86-devel-static-3.3.6-3.i386.rpm is part of the XFree86 distribution, it is a development package, statically linked, and the version number is 3.3.6-3. The name also denotes that it is a compiled binary program for processors compatible with the Intel 386 CPU. For further details on managing RPM packages, see Chapter 6 as well as the "Adding Software" section of Chapter 19.
The upgrade script uses RPM to query key packages installed under the current system, and determine their versions. This provides the guidance the script needs to understand what base version of COL is currently running. The script then interrogates the contents of the Packages/RPMS directory on the Install CD-ROM to determine what the upgrade target version is. With this information in hand, upgrade.col dynamically creates the upgrade script, which in turn performs the actual work of updating the current system.
The instructions for the upgrade script are in a file in the root directory of your Install CD-ROM. The file is called UPDATExx.txt, where the xx is "de," "fr," "it," or "us" for direction in German, French, Italian, or English, respectively. The following listing is a complete copy of the eDesktop 2.4 version of UPDATEus.txt. This resource is offered to you here, as it cannot be up on your screen simultaneously with the upgrade process.
--------------------------------------------------------------------------------
EXECUTING THE OPENLINUX 2.4.000.7 UPDATE SCRIPT February 2000
This section explains how to execute the OpenLinux 2.4.000.7 update script.
Before you execute the update script, you should read this entire document.
This document includes the following information:
- A word about the new version number scheme
- Obtaining the latest update script
- New features in the update script
- Executing the update script
A WORD ABOUT THE NEW VERSION NUMBER SCHEME
==========================================
You may have noticed that some version numbers have changed with this release
of the update.col script. The new update script is called "2.4.000.7"
Here's a description of each field in the version number (for example,
"update.col-2.4.000.7"):
- The First Number field indicates the major release.
- The Second Number field indicates the minor release.
- The Third Number field indicates the maintenance release.
- The Fourth Number indicates the iteration version of the script.
NOTE: To determine the version of a certain "update.col" script, enter
"./update.col --version".
OBTAINING THE LATEST UPDATE SCRIPT
==================================
To obtain the latest version of the update script, visit Caldera's FTP site at
ftp://ftp.calderasystems.com/pub/openlinux/updates/.
NEW FEATURES IN THE UPDATE SCRIPT
=================================
This update.col utility supports updating from COL 2.2 to newer OpenLinux
release levels.
Examples of updates:
OpenLinux-2.2-7 => OpenLinux-2.4-7
...
An update engine embedded within the script dynamically builds a script for
your machine based on your update path.
EXECUTING THE UPDATE SCRIPT
===========================
WARNING! Please follow these steps exactly.
1. Back up your existing system. It is always a good idea to back up your
system before updating software, especially since the update.col script
is a complex procedure.
2. Log in locally as the root user.
NOTE: To avoid problems with rebooting, don't log in as the superuser (su)
or as the root user over a network.
3. Insert the OpenLinux CD you are updating to.
4. Mount the CD-ROM (for example, enter "mount /mnt/cdrom").
All packages must reside in /mnt/cdrom/Packages/RPMS. In the case of a
security update distributed on diskette (as with OpenLinux Standard 1.1),
/mnt/floppy/security/RPMS is included in the package path and may be used
if the diskette has been mounted with the "mount /mnt/floppy" command.
If update packages reside in directories other than what was specified above
on the CD-ROM or diskette, see the usage notes by entering
"/sbin/update.col --help".
5. Copy the "update-2.4.000.7.tgz" file to the root directory (/) of your
filesystem (not "/root").
6. To extract the contents of the archive:
a. Access the root (/) directory (for example, enter "cd /").
b. Enter "tar zxvf update-2.4.000.7.tgz", where "2.4.000.7" is the
current update script. The "update.col" script is added to the /sbin
directory. Do not move the script! The script MUST reside in the root
filesystem partition for the update to function properly.
7. Have all users log off the system you're updating, then change to
runlevel 1 by entering "/sbin/telinit 1".
8. To show the steps that will occur when you execute the script:
a. Enter "/sbin/update.col --test". The "update.script" file is added to
the "/tmp/update.$PID" directory, where "$PID" is the process ID number
under which the test was run.
b. Verify the "update.script" file in the "/tmp/update.$PID" directory,
where "$PID" is the process ID number under which the test was run. Note
any problems that may conflict with your system's current configuration,
such as modifications to packages shipped by Caldera.
NOTE: The update script should not replace any custom updates you made.
9. To execute the update script, enter "/sbin/update.col".
Log files will be kept of what was done. The log files appear in the
"/tmp/update.$PID" directory, where "$PID" is the process ID number under
which the test was run.
If the system detected the update, you are prompted to reboot the system.
10. If you're asked if you want to reboot the system, enter "yes". If you're
not prompted to reboot the system, enter "/sbin/reboot" or enter
"/sbin/reboot -f".
If any e2fsck filesystem errors appear after the system reboots, disregard
them. These errors are caused by temporary files and the filesystem
automatically repairs them.
11. Check the log file.
If you encounter problems with this update, check the "update.log" file in
the "/tmp/update.$PID/update.log" directory, where "$PID" is the process ID
number under which the script was run.
Notes regarding the previous instructions:
/sbin/reboot -f. The "-f" requests a more complete verification of disk integrity during the reboot. Actually, the filesystem doesn't repair itself. The fsck (FileSystem Check) command, which is promoted by the -f portion of that reboot command, takes care of that detail. In the reboot following the upgrade, a number of file system errors are displayed and repaired without user intervention. The boot process is considerably longer than normal due to the repairs and extra checks.Running a test upgrade, as recommended in Step 8-a, is a good idea. The "verify" course of action referred to in Step 8-b is in fact recommending that you examine the file called update.script. Look to see if there is anything that can be recognized as being a problem. The advantage of the test run is that the updating "wizard" has a chance to examine the installed system in a non-interventional manner and show you which packages are going to be upgraded, only without commitment. The first part of an upgrade script looks like the following:
# =============================================================================
# update.col (version 2.4.000.7)
# =============================================================================
#
# Analyzing installed packages: OpenLinux-2.2-8 (col22u004)
# Analyzing available packages: OpenLinux-2.4-7 (col24core)
# Calculating update script for your system.
# This may take several minutes. Please wait.
# Calculating for update script done.
# Number of RPMs envolve[CT4]d in update: 1040
#
# =============================================================================
# update script for janus.syroidmanor.com on Sun Jul 23 14:57:03 PDT 2000
# =============================================================================
#
# =============================================================================
# Pass 1: update "core" packages
# =============================================================================
#
# the "rpm" group (to support newer RPM formats)
#
# ====== (Group_Begin) ======
# rpm update from 2.5.5-2 (col22core) to 3.0.3-1 (col24core)
# rpm-devel update from 2.5.5-2 (col22core) to 3.0.3-1 (col24core)
# Pkg_Ctrl remove rpm-devel 2.5.5-2
/bin/rpm -e --nodeps rpm-devel-2.5.5-2
# Pkg_Ctrl update rpm 2.5.5-2 3.0.3-1 u
/bin/rpm -U --nodeps /mnt/cdrom/Packages/RPMS/rpm-3.0.3-1.i386.rpm
# Pkg_Ctrl install rpm-devel 3.0.3-1 0
/bin/rpm -i --nodeps /mnt/cdrom/Packages/RPMS/rpm-devel-3.0.3-1.i386.rpm
# Pkg_Ctrl post rpm 3.0.3-1
# ======= (Group_End) =======
#
# the "lisa/info" group (to support newer postin scripts)
#
* * *
The update.col shell script dynamically creates the update.script file. Lines that start with # are comment lines, written into the script to document its activities. The current installed OpenLinux system, and the target system (2.2-8 and 2.4-7, respectively) are noted. The number of RPM packages due for updating in the example shown is 1,040. Run date and time are given.
Following the informational header portion of the file, the active section of the update script begins. For each piece of software referenced in the script the old package is either updated or removed, as in the line /bin/rpm -e -nodeps rpm-devel-2.5.5-2, which uses the RPM utility to remove (rpm -e) the development package without regard to the implications for other software on the system (nodeps = no dependencies). As shown in the previous fragment, the RPM tool itself is then updated (rpm -U ...) on the next non-comment line. Then the new version of the RPM development package is installed (rpm -i ...).
Actually, running the upgrade (as opposed to a test run) can take anywhere from 25 to 45 minutes on a fast system with a speedy CD-ROM drive, to over an hour on slower hardware. A nice feature is that during the update, the script's activities are echoed to the console so you can monitor the process as it completes.
Following the upgrade, it is important that you follow the instruction to reboot. The update process, in forcing the removal of packages without regard for dependencies, leaves behind broken links and other detritus that can only be cleared by a filesystem check. The easiest way to accomplish this is by executing the command, /sbin/reboot -f, as previously discussed.
As you have probably surmised from our discussions so far, upgrading a system is not always as seamless and trouble-free a procedure under Linux. Generally speaking, upgrading a system will result in one of two outcomes: Good Enough, and Not Good Enough. We'll tackle the easy one first.
What is "Not Good Enough"? This outcome means it's going to take more than a couple of hours to repair all the parts of the system software that aren't working, and you have a tested good backup. In this case, our recommendation is to wipe the partition(s) and install the new version from scratch. This yields a known good system, into which you can restore both data and programs. We have found this to be generally true, no matter which operating system we're working with.
"Good Enough" is a little trickier. For instance, in our upgrade of COL 2.2 to 2.4, most of the function icons and various other visual bits of the version of WordPerfect packaged with 2.2 broke. We tried to repair this by manually removing WP from the system, then reinstalling it from base RPMS on the older installation CD-ROM. Our attempted repair didn't work - there is an incompatibility that requires an update we couldn't identify without more effort than we cared to apply. With that one exception, however, the upgrade of a relatively pristine COL 2.2 system up to a base 2.4 installation went reasonably well.
After the update and reboot, inspect the files in the /tmp/update.xxxx directory (where xxxx is the PID or process ID number the update script ran as). The directory listing resembles the following output:
[tom@janus update.19472]$ ls
cmd.meta names.childs pkgs.installed update.errors update.script
daemon.status pkgs.available pkgs.workset update.log update.tbl
names.available pkgs.childs rpmextr update.reboot
There are two files partially displayed below, representative of the data found in similar files on any upgraded OpenLinux system. Scan briefly through the update.errors, which is the first listing, looking for programs that should be tested for functionality (for example, xemacs appears to have encountered upgrade problems) that should be tested for functionality. The second partial listing is of update.log. This file is a direct copy of the output to the console window during the script run, and is useful for reviewing all the events of the update, as opposed to just the errors.
[tom@janus update.19472]$ cat update.errors | less
old format database is present; use --rebuilddb to generate a new
format database
error: cannot open //var/lib/rpm/packages.rpm
warning: /etc/system.cnf saved as /etc/system.cnf.rpmsave
file /usr/info/cl.info-1.gz from install of xemacs-base-21.1.8-3
conflicts with file from package xemacs-lispprog-20.4-4
file /usr/info/cl.info-2.gz from install of xemacs-base-21.1.8-3
conflicts with file from package xemacs-lispprog-20.4-4
file /usr/info/cl.info-3.gz from install of xemacs-base-21.1.8-3
conflicts with file from package xemacs-lispprog-20.4-4
* * *
[tom@janus update.19472]$ cat update.log | less
# ========================================================================
# update.col (version 2.4.000.7)
# ========================================================================
#
# Analyzing installed packages: OpenLinux-2.2-8 (col22u004)
# Analyzing available packages: OpenLinux-2.4-7 (col24core)
# Calculating update script for your system.
# This may take several minutes. Please wait.
# Calculating for update script done.
# Number of RPMs envolved in update: 1040
#
# ========================================================================
#update script for janus.syroidmanor.com on Sun Jul 23 14:57:03 PDT 2000
# ========================================================================
#
# ========================================================================
# Pass 1: update "core" packages
# ========================================================================
#
# the "rpm" group (to support newer RPM formats)
#
# ====== (Group_Begin) ======
# rpm update from 2.5.5-2 (col22core) to 3.0.3-1 (col24core)
# rpm-devel update from 2.5.5-2 (col22core) to 3.0.3-1 (col24core)
# Pkg_Ctrl remove rpm-devel 2.5.5-2
/bin/rpm -e --nodeps rpm-devel-2.5.5-2
# Pkg_Ctrl update rpm 2.5.5-2 3.0.3-1 u
/bin/rpm -U --nodeps /mnt/cdrom/Packages/RPMS/rpm-3.0.3-1.i386.rpm
# Pkg_Ctrl install rpm-devel 3.0.3-1 0
/bin/rpm -i --nodeps /mnt/cdrom/Packages/RPMS/rpm-devel-3.0.3-1.i386.rpm
old format database is present; use --rebuilddb to generate a new format database
error: cannot open //var/lib/rpm/packages.rpm
# Pkg_Ctrl post rpm 3.0.3-1
# ======= (Group_End) =======
#
* * *
Following the update, if everything appears to be working as expected on the surface, take the time to test the key applications you work with on a routine basis. Try out the COAS (Caldera Open Administration System) features, and as many of the other system and application programs as possible. If your tests turn up a disproportionate number of non-functional programs, now's the time to weigh the costs of fixing things against a clean installation. Better now, rather than weeks down the road after you've spent numerous hours applying personal tweaks and configuration changes.
If a program dumps core (where the program dies, and in it's final throes creates an image of system memory so that someone can figure out what happened), or produces a segment fault (aka segfault) on execution (two common modes of program failure under Linux), check to see if it's a program you installed manually under the prior version of OpenLinux. If so, recompile the source code and re-install from scratch. This allows the program to dynamically link to the new libraries installed with the upgrade.
Tip
If after a system upgrade you find your desktop configuration is broken (for example, menus and icons that don't function), delete the files ~/.kde and ~/.kderc located in your home directory (typerm -rf .kde*from a terminal window or from a console login session). Next, reload the X session by logging out, restarting X, then logging back in again. This sequence of steps reloads the default KDE configuration files that control KDE's menus and layout. Finally, reconfigure the setup to individual tastes. We found this to be a useful exercise as a general follow-up to any upgrade, as it freshens and rebuilds the KDE menus entirely.
It's important to always check the security of a system after implementing any major software changes. This is especially critical after a system upgrade due to the fact that existing configuration files are often overwritten during the process. In other words, a system deemed secure before an upgrade will often be returned to an insecure state by virtue of the update routines.
For example: One of our personal systems is connected to a cable modem. Because the machine's only function is to provide NAT (Network Address Translation, also known as connection sharing) to other machines on the Syroid Manor network, nearly all open ports had been disabled to keep the "bad guys" out (for a detailed overview of securing a Linux system, see Chapter 21).
Upgrading this system re-enabled many of the inetd services that had previously been turned off. These included ftp, telnet, shell, login, exec, talk, ntalk, finger, ppp-socket, auth, and swat. To remove these services from active duty, comment out each respective line from the /etc/inetd.conf file.
Other system daemons remained mostly quiescent. The Sendmail configuration wasn't altered, nor was the httpd service (the Apache HTML server). However, our update installed Cameleo Light, an introductory version of Caldera's document management system. This starts two system daemons, keyserver and calserver, that run on exposed ports. To disable these, you'll need to either remove Cameleo from the system daemon list via COAS, or disable it manually by editing /etc/sysconfig/daemons/cameleo, changing the value of the parameter ONBOOT to no.
A Note from Kurt Wall, Technical Editor
The upgrade option is being totally rewritten. As it is, I don't recommend using it. It is better overall just to back up the data you want to save, install from scratch, and restore your backed up data.
Thanks, Kurt - that's just what we had in mind. Since this is such a prominent option in the distribution, we figured that it's best to cover this base... Generally speaking, we do not recommend upgrading a Linux installation. Exceptions to this rule include systems that have had few or no software updates applied since they were first installed (a rarity), and systems that reside on a single partition.
Part of the reason we do not typically upgrade a system lies in the structures and routines we use when installing any variant of Unix:
The upgrade scripts provided by Caldera are potentially useful in a limited range of circumstances. While we were unable to uncover any major flaws in the upgrade process, we retain significant doubts about the overall reliability of the process. When possible, preserve your data with a tested backup, install your new system software, and then restore your data. This chapter covered the following points:
/sbin/update.col --test once the script is installed. When the script completes, scan through the resultant files in /tmp/update.nnnn (where the "nnnn" represents the process ID of the running update) for potential troublespots./sbin/reboot -f at the command prompt. This forces a full filesystem check during the boot process to repair minor errors caused by the upgrade.Go to the Table Of Contents