Upgrading your Linux system

NEW RELEASES OF LINUX come out periodically, driven by healthy competition between the major Linux distribution vendors as well as the "release early, release often" philosophy that guides most Open Source projects. For example, the latest Mandrake 9.1 has just been released recently, followed shortly by the new Red Hat 9 appearing this week.

This can seem to present a dilemma for the home Linux user who has only a single PC. Should they cross their fingers and take the leap, trusting that the newer version will be better than the old? Or should they stick with what they've already got configured and working, on the theory that "if it ain't broke, don't fix it", and upgrade only when they must, for new application or device support?

Upgrading to the latest release of a major Linux distribution is usually a fairly low-risk proposition. But software progress is never entirely risk free. Indeed, software is always a three steps forward, one step back type of process. Facilities get rewritten and new features are added, so bugs exist in new code until a few weeks or months have passed and patches get built and applied. Many production Linux systems don't get upgraded until the following release appears, that is, they remain at least one release behind the most recent version. However, such care isn't usually required with a personal workstation, provided one takes a professional approach. It just delays the fun of nifty new software.

This characteristic of new software releases is not in any way unique to Linux. It also holds true for even the most rigorously managed and well tested mainframe OS software like IBM's Z/OS and VM, big-tin UNIXen like IBM's AIX, Sun's Solaris and HP's HPUX, as well as (or especially) all of Microsoft's baroque, bug-infested, user tested operating systems.

Testing a new OS release usually isn't a problem in any big commercial IT environment, because they all have spare machines, development boxes, or test partitions on large systems reserved for just such tasks. Even people who work in IT industry professions have more than one system around by now, so for them testing new OS releases just means loading a secondary machine that they happen to have handy for such purposes.

So what's the casual home Linux user to do? A good approach is the one followed by IT professionals on the large production systems, which is to always maintain a working backup of the previous production system as an alternative in case a new system fails or develops behaviour problems that make sudden operating system reversion the better part of valor.

On mainframe systems, such a prudent approach is implemented through the definition of an alternate system disk. Then, to revert to the previous production system, the operator merely specifies a different load unit. And fortunately, you can do essentially the same thing using Linux.

Perhaps the best way to do this is to install a second hard drive in your PC. It's easy to add a second IDE hard drive to most tower PCs - you'll only need to add a second IDE cable and properly set any master/slave jumper(s) on your mainboard. If you happen to have a SCSI disk subsystem, you likely have more than one hard drive already, or at least a spare connector on your SCSI cable just waiting for use. Most notebook PCs won't accommodate a second hard drive but, as with any multi-boot scheme, you can always set up multiple Linux versions on a single disk system, provided that you happen to have enough disk space available.

In a following article, I'll explain and outline the simple process of cloning a running Linux system and setting up for a release upgrade. µ