Upgrading Your linux Distribution mini-HOWTO

Greg Louis

       This e-mail address is being protected from spambots. You need JavaScript enabled to view it

Hints and tips on upgrading from one linux distribution to another. This is version 1.2, 2002-03-09.

2. Changes since version 1.1

  • Converted to docbook

  • Corrected some obsolete information

  • Added this history section

  • Added Zoltán Hidvégi's suggestion re mtime and ctime. Thanks, Zoltán!

  • Added an Acknowledgements section

3. Introduction

3.1. How to slay and reincarnate your linux box!

The purpose of this document is to offer tips to help you through the destruction and reinstallation of a linux system. It's not a foolproof cookbook by any means, but I hope it will serve as some indication of what you need to think about, and of the order in which to do things. It would have been a help to me, if someone else had written something like this before I did my first upgrade; so I hope it will be a help to you, if you have a linux machine to rebuild.

Don't take it as gospel, though: your mileage will almost certainly vary. Even the directory names in this document may be different from the ones you need to use; some people have /usr/home instead of /home, for example; others call it /u, and some (delicate shudder :) even put all their users directly under /usr itself! I can't be specific about your system, so I've just used the names the way they are in mine.

You'll also notice that I use Slackware distributions, and that I assume you've enough RAM and hard disk space to install linux kernel source and build your own kernel. If your system is different, some of my recommendations won't apply; but I hope you'll still find the general outline to be of assistance in your rebuild project.

3.2. Why would anyone want to do that?

Good question! If it can possibly be avoided, don't do it! (That's the single most important recommendation in this whole guide!!!) When this guide was first written, not many people had hard disks big enough to accomodate two whole Linux installations; these days, that's by no means uncommon. If you possibly can, build your new system in a separate partition (or group of partitions), keeping the old one intact till you're satisfied that the new one is just the way you want it. If you can avoid destroying the old system to make room for the new, by all means avoid it! But there are times when you may have no choice.

(These examples are a bit dated, but they serve to illustrate my point:)

For example, I installed a 4Gb hard disk and then found out that Slackware 2.0 vintage linux didn't know a hard disk could have more than 2Gb, and it got horribly confused. So I had to upgrade to the then-current Slackware 2.3. That upgrade was a gruelling experience, and it's part of the reason I'm writing these notes. I did just about everything wrong, and only good luck and the fact that I had another running linux box beside me saved me from disaster.

As another example, I found that I just couldn't succeed in building a working a.out linux kernel in the 1.3 series, using an out-of-the-box Slackware 2.3 installation (another machine, not the one I botched before). I took the plunge, bought Slackware 3.0 on CDROM and converted to ELF. This time the reinstallation went better, thanks in part to the previous bitter experience, and it served as the source of most of the ideas I'm offering you here.

3.3. Do you have to ``destroy and reinstall?''

See above. If you can build your new system in otherwise empty disk space, do it! For the rest of this document, however, I'll assume that this is one of those times when that option isn't available; you either have to reinstall "in place," over top of the existing system, or you have to bite the bullet and rebuild from scratch.

The latter is safer, oddly enough. If you install over top of an existing linux system, chances are you'll have a mixture of old and new binaries, old and new configuration files, and generally a mess to try to administer. Wiping the system clean, and then putting back only what you know you need, is a drastic but effective way to get a clean result. (Of course we're talking about installing a whole new linux distribution here, not about upgrading one or two packages! The best way to avoid having to do a full reinstallation is, precisely, to keep the individual bits -- especially gcc and its libraries, and binutils -- current. If the stuff you use is reasonably up-to-date, and you can keep it so by bringing in, and if need be compiling, new code from time to time, then there's no need for a mass upgrade.)

5. Make a full backup of the existing system.

Generally speaking, big backups tend to be written on media that are sequentially accessed. That being so, you won't want to use this complete backup for restoring significant numbers of files; it's got too many files on it that you don't want. It's better to create small backups of individual segments that you know you're going to restore in their entirety. I'll list a bunch of examples later.

Why then should you start with a full backup? Two basic reasons: first, in the event of a catastrophic failure installing the new system, you'll have a way to get back to the starting point with minimum pain. Second, no matter how carefully you prepare for the new installation, there is a very large chance that one or two important files will be overlooked. In that case the clumsiness of restoring those one or two files from the full backup set will be preferable to the inconvenience of doing without them.

To save time and space, if you've still got the distribution medium for your old linux version, you might want to back up only those files the mtime or ctime of which is more recent than the date of the original installation.

7. Make separate backups of each group of files you want to preserve.

This is the most variable part of the job, and all I can really do to help is to describe what I did in my system, in the hope that it will serve as a rough guide. Basically, you want to look at every directory that contains any

  • files that aren't part of your standard linux installation, or

  • files that are actually newer than the ones you'll install when you do your new linux installation.

and separate out only those files that you want to carry over.

(Another possible strategy is to back up all files with mtime or ctime more recent than the day of the previous linux installation, as mentioned above, and then restore from that. If you do that, you have to take into account that the new linux distribution may contain versions of some files that are newer still than the ones you saved.)

In my case, I ended up making a .tgz file on the backup medium for each of

  • /usr/lib/rn

  • /usr/lib/smail

  • /usr/lib/trn (the rest of /usr/lib would be reinstalled)

  • /usr/local/src

  • /usr/local/bin

  • /usr/local/lib

  • /usr/local/lpfont

  • /usr/local/man

  • /usr/local/sbin

  • /usr/local/thot (there were other /usr/local files I didn't need)

  • /usr/openwin

  • /usr/src/lilo-17 (because my new Slackware still had version 16)

  • /usr/src/linux-1.2.13 (because I'd done some customizing)

  • /usr/X11R6/lib/X11/app-defaults

  • /usr/X11R6/lib/X11/initrc (the rest of Xfree86 was to be reinstalled)

  • /var/named

  • /var/openwin

  • /var/texfonts

My machine was relatively easy in that there were no spool files to worry about. I don't run a news spool on this box, and since there are only two users, it was easiest just to get all the mail read before shutting down. Otherwise, /var/spool directories would have had to be backed up at the last minute. (And, of course, the news library and site directories!)

9. Format floppies for the temporary kernel and the final build.

You'll need two, one floppy for each.

After all that's done, you're ready for the Big Moment. The next step removes the system from production.

13. Run the new linux installation.

There are already several good documents describing how to do this, so I'm not going into any detail. Continue from here when the new system can boot from its hard disk.

Along the way, be sure to make a floppy that you can boot as well, since the kernel that the linux setup installs has to be replaced and accidents can happen during that process. Be sure to install the development packages and the kernel source.

17. Review security.

(Sigh...) When I wrote this, this step was important but not crucial; the Internet was a friendlier place even in 1996 than it is today. Now, if your machine has Internet access, this step is utterly vital, and there are whole books devoted to getting it right; I can do nothing more here than offer a few very basic pointers:

Check file permissions and directory permissions to be sure that access is neither too restricted nor too easy. I find that Slackware tends to lean toward a more open environment than I like, so I go around changing 755's to 711's for binaries in the .../bin directories and stuff like that. Or even 700's in the .../sbin ones. Especial care is needed if you've carried over ftp, telnet or web servers; but then, if you were running those, you probably thought of that already. :)

Look at /etc/inetd.conf or /etc/xinetd.conf and make sure you're not running any Internet services you don't need to. Also go through the boot scripts in /etc/rc.d and friends for the same purpose. Check your firewall rules if your box is an Internet gateway or has Internet access.



Subscribe to Comments Feed

Upcoming Linux Foundation Courses

  1. LFD312 Developing Applications For Linux
    05 Jan » 09 Jan - Virtual
  2. LFS220 Linux System Administration
    05 Jan » 08 Jan - Virtual
  3. LFD331 Developing Linux Device Drivers
    12 Jan » 16 Jan - Virtual

View All Upcoming Courses

Become an Individual Member
Check out the Friday Funnies

Sign Up For the Newsletter

Who we are ?

The Linux Foundation is a non-profit consortium dedicated to the growth of Linux.

More About the foundation...

Frequent Questions

Join / Linux Training / Board