home *** CD-ROM | disk | FTP | other *** search
/ BURKS 2 / BURKS_AUG97.ISO / BURKS / LINUX / HOWTO / mini / upgrade.txt < prev    next >
Text File  |  1997-07-07  |  15KB  |  343 lines
  1.   Upgrading Your linux Distribution mini-HOWTO
  2.   Greg Louis, glouis@dynamicro.on.ca
  3.   v1.11, 6 June 1996
  4.  
  5.   Hints and tips on upgrading from one linux distribution to another.
  6.  
  7.   1.  IMPORTANT!!! Disclaimer and Copyright
  8.  
  9.   The procedure to which this document attempts to be a guide is
  10.   inherently dangerous to the programs and data stored in your computer.
  11.   You carry out any such procedure entirely at your own risk.  The steps
  12.   described in this document worked for the author; there is no
  13.   guarantee that they will work for you, nor that you can attempt to
  14.   follow them without serious damage to your computer's programs and/or
  15.   data.  You are entirely on your own in any use you may make of the
  16.   information presented herein, and the author shall not be liable in
  17.   any way whatsoever for any damage or inconvenience of any kind that
  18.   you may suffer in so doing.
  19.  
  20.   This document is copyright 1996, Dynamicro Consulting Limited, and is
  21.   released under the terms of the GNU General Public License.  This
  22.   basically means that you may copy and modify it at will, but may not
  23.   prevent others from doing likewise.
  24.  
  25.   Comments and questions may be directed to the author.  Especially
  26.   welcome, for use in future revisions, are accounts of successful
  27.   upgrades of complex systems.
  28.  
  29.   2.  Changes since version 1.1
  30.  
  31.   ╖  Added this history section
  32.  
  33.   ╖  Added Zoltßn HidvΘgi's suggestion re mtime and ctime.  Thanks,
  34.      Zoltßn!
  35.  
  36.   ╖  Added an Acknowledgements section
  37.  
  38.   3.  Introduction
  39.  
  40.   3.1.  How to slay and reincarnate your linux box!
  41.  
  42.   The purpose of this document is to offer tips to help you through the
  43.   destruction and reinstallation of a linux system.  It's not a
  44.   foolproof cookbook by any means; but I hope it will serve as some
  45.   indication of what you need to think about, and of the order in which
  46.   to do things.  It would have been a help to me, if someone else had
  47.   written something like this before I did my first upgrade; so I hope
  48.   it will be a help to you, if you have a linux machine to rebuild.
  49.  
  50.   Don't take it as gospel, though: your mileage will almost certainly
  51.   vary.  Even the directory names in this document may be different from
  52.   the ones you need to use; some people have /usr/home instead of /home,
  53.   for example; others call it /u, and some (delicate shudder :) even put
  54.   all their users directly under /usr itself!  I can't be specific about
  55.   your system, so I've just used the names the way they are in mine.
  56.  
  57.   You'll also notice that I use Slackware distributions, and that I
  58.   assume you've enough RAM and hard disk space to install linux kernel
  59.   source and build your own kernel.  If your system is different, some
  60.   of my recommendations won't apply; but I hope you'll still find the
  61.   general outline to be of assistance in your rebuild project.
  62.  
  63.   3.2.  Why would anyone want to do that?
  64.  
  65.   Good question!  If it can possibly be avoided, don't do it!  (That's
  66.   the single most important recommendation in this whole guide!!!)  But
  67.   there are times when you may have to.
  68.  
  69.   For example, I installed a 4Gb hard disk and then found out that
  70.   Slackware 2.0 vintage linux didn't know a hard disk could have more
  71.   than 2Gb, and it got horribly confused.  So I had to upgrade to the
  72.   then-current Slackware 2.3.  That upgrade was a gruelling experience,
  73.   and it's part of the reason I'm writing these notes.  I did just about
  74.   everything wrong, and only good luck and the fact that I had another
  75.   running linux box beside me saved me from disaster.
  76.  
  77.   As another example, I found that I just couldn't succeed in building a
  78.   working a.out linux kernel in the 1.3 series, using an out-of-the-box
  79.   Slackware 2.3 installation (another machine, not the one I botched
  80.   before).  I took the plunge, bought Slackware 3.0 on CDROM and
  81.   converted to ELF.  This time the reinstallation went better, thanks in
  82.   part to the previous bitter experience, and it served as the source of
  83.   most of the ideas I'm offering you here.
  84.  
  85.   3.3.  Do you have to ``destroy and reinstall?''
  86.  
  87.   It's safer, oddly enough.  If you install over top of an existing
  88.   linux system, chances are you'll have a mixture of old and new
  89.   binaries, old and new configuration files, and generally a mess to try
  90.   to administer.  Wiping the system clean, and then putting back only
  91.   what you know you need, is a drastic but effective way to get a clean
  92.   result.  (Of course we're talking about installing a whole new linux
  93.   distribution here, not about upgrading one or two packages!  The best
  94.   way to avoid having to do a full reinstallation is, precisely, to keep
  95.   the individual bits -- especially gcc and its libraries, and binutils
  96.   -- current.  If the stuff you use is reasonably up-to-date, and you
  97.   can keep it so by bringing in, and if need be compiling, new code from
  98.   time to time, then there's no need for a mass upgrade.)
  99.  
  100.   As Patrick Volkerding points out (he too recommends the wipe-it-clean
  101.   procedure for upgrades), installing ELF on top of a running a.out
  102.   system is a recipe for disaster; at least, if you know enough to try
  103.   it, you needn't read this guide!
  104.  
  105.   Even without that complication, though, you're better to build from
  106.   scratch.
  107.  
  108.   3.4.  How long will it take?
  109.  
  110.   Depends, of course, on how complex your system is.  But I figure that,
  111.   for the successful upgrade (the other one? -- don't ask! :) I spent
  112.   about ten hours making backups, six hours rebuilding the system to the
  113.   point where I could enable logins, and another half day or thereabouts
  114.   restoring the less-crucial stuff.  As time passes I keep discovering
  115.   little things that still aren't exactly as I want them -- I fix these
  116.   as they're encountered -- but in the main, twenty hours' work should
  117.   suffice for a reasonably complex rebuilding job.  Maybe less if you're
  118.   reinstalling from hard disk (I used CDROM) or more if you need to
  119.   install from floppies.  Maybe less if you've got a fast Pentium, more
  120.   if it's a 386.  You get the idea.
  121.  
  122.   So much for the introduction.  Here's how to set about it, once you've
  123.   decided it must be done.  Arm yourself with fortitude and Jolt or
  124.   whatever, and:
  125.  
  126.   4.  Write down everything you do.
  127.  
  128.   It's extremely valuable to have a record of what you've done in the
  129.   process of preparing for, and carrying out, the changeover.
  130.   Especially important is a list of the backups you'll be making in
  131.   preparation for the destruction of your existing system.
  132.  
  133.   5.  Make a full backup of the existing system.
  134.  
  135.   Generally speaking, backups tend to be written on media that are
  136.   sequentially accessed.  That being so, you won't want to use this
  137.   complete backup for restoring significant numbers of files; it's got
  138.   too many files on it that you don't want.  It's better to create small
  139.   backups of individual segments that you know you're going to restore
  140.   in their entirety.  I'll list a bunch of examples later.
  141.  
  142.   Why then should you start with a full backup?  Two basic reasons:
  143.   first, in the event of a catastrophic failure installing the new
  144.   system, you'll have a way to get back to the starting point with
  145.   minimum pain.  Second, no matter how carefully you prepare for the new
  146.   installation, there is a very large chance that one or two important
  147.   files will be overlooked.  In that case the clumsiness of restoring
  148.   those one or two files from the full backup set will be preferable to
  149.   the inconvenience of doing without them.
  150.  
  151.   To save time and space, if you've still got the distribution medium
  152.   for your old linux version, you might want to back up only those files
  153.   the mtime or ctime of which is more recent than the date of the
  154.   original installation.
  155.  
  156.   6.  Back up /etc and its subdirectories on one or more floppies.
  157.  
  158.   This is the other extreme: you won't be restoring these files (for the
  159.   most part, anyway); you'll be comparing them with the new ones that
  160.   get created during installation.  Why?  Because the new ones may have
  161.   data that the old ones didn't, or may express the old data in new
  162.   ways.  Changes in protocols, addition of new tools, or implementation
  163.   of new features in existing tools may all dictate changes in the
  164.   formats of the configu