Small LS logo

Optimising the Linux upgrade process

There are a number of ways to make Linux maintenance easier. The approach described here is designed to minimise the effort involved in upgrading to the next release of your distro. Since this will be done once or twice a year its worthwhile organising things to make the process as fast and simple as possible and also to keep track of the extra software you'll want to continue using after the upgrade. Few things are more annoying than finishing a clean install only to find that some package you use a lot is missing and then you don't remember where you got it from when you installed it last year.

This guide is written round RedHat's Fedora distro but should be readily adaptable to most other distros.

Why only doing clean installs is a good idea

If you've added much stuff to your setup you may well find that upgrading to the next release of your distro is (a)slow and (b)doesn't work, so personally I only do clean installs, but there are ways of organising yourself and the installation so that's easier.

Preparing to use the clean install approach

You have some preparatory work to do on the existing installation before you can use this approach for the first time. The essentials are:

  1. Move the /usr/local directory to /home/local and replace it with a symlink to /home/local.
  2. Do the same for anything else under /usr that isn't part of the standard distro, e.g. Oracle Java. See below for details.
  3. Do the same for anything under /var that you'd like to back up alongside the contents of /home. Suitable candidates are the Apache root directory, Postgres or MySQL database storage, cvs repository, etc. You'll also need to change their configurations, check that they still work and make copies of the modified configurations somewhere that will be safe. Putting the copies in your development user solves that problem. See below for details.
  4. Back up the contents of the, now extended, /home directory tree.
  5. Run 'df -h' and print or otherwise preserve its output. You'll need it when you're deciding how big to make the various partitions in your customised disk layout. You'll probably also want to refer to it as you install each new release of your distro as a reminder of what partition goes on each mount point and which of them MUST NOT be reformatted. You don't have to repartition the disk next time but you do have to tell the installer how to map file systems to partitions.

How to do a clean install without losing any data

The key idea is to make /home into a separate partition. Doing this means that you can format every other Linux partition on the disk and do a clean install without losing any personal data. The steps are:

  1. Start the installer and test the installation media as usual.
  2. Tell the installer you want to do a custom install. This lets you describe your chosen partitioning scheme to it rather than blindly using whatever the installer's designer thought you'd want. When you're happy it will format the partitions and do the rest of the installation as usual except that it configures the system to auto-mount all the partitions. The default for most distros is to use as few partitions as possible. Often that means three: I think a more sensible scheme involves at least four partitions: In addition I separate out /tmp so a runaway process is less likely to crash the system by filling it. I add a few extra touches that make post installation configuration much faster and avoids the need to restore any data if the install is replacing the version of Fedora on the same disk:
  3. After a clean install and an immediate update to pick up the latest kernel and updated packages:

I've now scripted everything described above that can be automated apart from checking config files, putting them back and starting the services, so all the 'just do it' steps take about 5-10 minutes to run. Its that long because the script also installs the 30-40 'extra' Fedora packages I use plus a few from rpmfusion and atrpms. Without this yum activity the scripts would run in about 30 seconds.

The process of restoring configuration files for the major services and then starting them remains a manual procedure because distro upgrades typically install a later version of these services and this often means that the configuration parameters have changed as well: I use diff to see what has changed and then decide whether to continue using my original configuration files or to apply my changes to the newer files and, after verifying that everything is working correctly, replace my backup configuration file set with the new one.

As I said above, another reason for working this way is that an upgrade seems to take around twice as long as a clean install. This is not surprising when you remember that it has to compare all the files before it can delete and reinstall any file that has changed. I could probably live with that if it worked, but almost every time I've tried an upgrade the system has been trashed and I've had to do a clean install after all. In fact RedHat has now realised that upgrading across a version boundary usually fails and has removed that choice. However, a cross-version upgrade is still the preferred option for Debian stable installations and, presumably, for Debian-derived distros too.