LDP/LDP/howto/docbook/rpmupgrade.sgml/rpmupgrade.xml

2972 lines
87 KiB
XML
Raw Normal View History

<?xml version="1.0" standalone="no"?>
<!DOCTYPE ARTICLE PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"/usr/share/sgml/docbook/xml-dtd-4.1/docbookx.dtd" [
<!ENTITY GFDLDOC SYSTEM "fdl.xml">
]>
<!--ENTITY GFDLDOC SYSTEM "fdl-1.2-draft.xml"-->
<!--DOCTYPE ARTICLE PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"-->
<!--DOCTYPE ARTICLE PUBLIC "-//OASIS//DTD DocBook V4.1//EN"
"/usr/share/sgml/docbook/sgml-dtd-4.1/docbook.dtd"-->
<!--DOCTYPE ARTICLE PUBLIC
"/opt/kde2/share/apps/ksgmltools/dtd/kde.dtd"-->
<article class="whitepaper" id="rpmupgrade">
<title>UNDER DEVELOPMENT -- RPM download and upgrade -- UNDER
DEVELOPMENT</title>
<articleinfo>
<copyright>
<year id="copyyear">2002</year>
<holder id="authorname">Steven Sanfratello</holder>
</copyright>
<pubdate role="rcs">$Date$</pubdate>
<pubsnumber>$Name$</pubsnumber>
<abstract>
<para>The GNU/Linux world asserts that the operating system can
be downloaded from the Internet and installed for no money. It
is easiest to install GNU/Linux on a fresh partition. But in my
readings I was always left wondering if it is also possible to
upgrade an existing distribution without destroying it. Here is
a description of upgrading a GNU/Linux distribution to the next
major release from the same distributor, using the downloaded
binary rpm packages.</para>
<para>Upgrading using downloaded, binary
<acronym>rpm</acronym>
packages has its advantages and disadvantages. It took me about
a week and a half to download a little over 600 Megabytes,
using a 56K modem. A few days after that I was done upgrading
the packages. Things did not go smoothly for me. But I'll
explain how to correct the pitfalls that I encountered, so that
you will spend less time when you upgrade.</para>
</abstract>
</articleinfo>
<remark>THIS DOCUMENT IS STILL UNDER DEVELOPMENT. PLEASE, HOLD ANY
CRITISISMS UNTIL I'M FINISHED WRITING IT.</remark>
<sect1 id="copyleft">
<title>GNU Copyleft</title>
<sect2>
<title id="twolicense">Copyright and Licensing Notice</title>
<para>Copyright (c) Steven Sanfratello. Permission is granted
to copy, distribute and/or modify this document under the terms
of the GNU
<ulink url="http://www.gnu.org/copyleft/fdl.html#TOC2">Free
Documentation License, Version 1.1</ulink>
or any later version published by the Free Software Foundation;
with the Invariant Sections being
<link linkend="twolicense">Copyright and Licensing
Notice</link>
and
<link linkend="twowarranty">Warranty</link>
with no Front-Cover Texts and with no Back-Cover Text. A copy
of the license is included in the section entitled "
<link linkend="gfdl">GNU Free Documentation License</link>
<!-- FIXME: extra white space -->
".</para>
<para>The author can be contacted at
<email>nevets72@a1isp.net</email>
and failing that, try the LDP discussion list at
<email>discuss@linuxdoc.org</email>
<!-- FIXME: extra white space -->
.</para>
<para>If you are profiting, in any way, from use or
distribution of this document please consider giving something
back to the author or to the Linux community and then act on
those considerations.</para>
</sect2>
<sect2>
<title id="twowarranty">Warranty</title>
<para>Although every precaution has been taken in the
preparation of this HOWTO, the publisher and author assume no
responsibility for errors or omissions. Neither is any
liability assumed for damages resulting from the use of the
information contained herein.</para>
</sect2>
</sect1>
<sect1 id="introduction">
<title>Introduction</title>
<indexterm>
<primary>Introduction</primary>
</indexterm>
<sect2>
<title id="twowhere">Where is the latest version?</title>
<para>Get the latest version of this HOWTO from :
<simplelist type="vert">
<member>
<ulink url="http://members.a1isp.net/nevets72/rpmupgrade/">
HTML Version on my web page</ulink>
</member>
<member>
<ulink
url="http://cvsview.linuxdoc.org/index.cgi/howto/docbook/rpmupgrade.sgml/">
Docbook XML Linuxdoc CVS</ulink>
</member>
<member>
<ulink
url="http://members.a1isp.net/nevets72/rpmupgrade/rpmupgrade.xml">
Docbook XML source on my web page</ulink>
</member>
</simplelist>
</para>
</sect2>
<sect2>
<title id="twopurpose">Purpose of this document</title>
<para>There are many reasons that you might want to read
this.</para>
<para>If you are considering taking advantage of the freely
downloadable versions of Linux you should know that it takes
some effort and know-how to accomplish. This HOWTO gives you
real picture of the effort required before you start the
process. In that way it will help you decide if the big
download and upgrade is worth the trouble.</para>
<para>Whether you decide to download or you obtain the rpm
packages on disk, then this will explain what it takes to do
the upgrade. Most commercial distributions are packaged as
binary rpms, so I thought that a HOWTO on a major upgrade would
be useful. The most important factor when upgrading the rpms is
choosing the right order
<emphasis>(hint: start with the libraries.)</emphasis>
</para>
<para>If you're having problems using your installation program
because it isn't reducing the packages down to fit on your
harddisk, this method gives you control over the packages to
eliminate what you don't need. That control allows you to
customize your install to almost any size that you want. While
several installation programs give you this level of control,
some do not.</para>
<para>This is not a proceedural HOWTO. I'll give you a
description of what I went through to set up and upgrade my
system and the reasoning behind it. From that description you
can get an idea of what's involved when doing similar upgrades
to your system. There are many different programs that can be
used for this process. I'll touch on many of them.</para>
<para>This is not a HOWTO about upgrading a single program,
with its dependancies. That knowledge can be obtained from the
<application moreinfo="none">rpm</application>
documentation. But if you find that there are so many new
dependancies that package requires, and you've worked the
dependancies all the way down to the kernel, you may decide
that it's time to upgrade the whole distribution.</para>
</sect2>
<sect2>
<title id="twohowlong">How long does it really take?</title>
<sidebar>
<para>Over all, it took about one and a half weeks to
download the packages. The binary rpms total size was a
little over 600 Megabytes. It took a few more days to do the
upgrading.</para>
<para>A more automated
<acronym>FTP</acronym>
proceedure would reduce the download time significantly. The
<acronym>FTP</acronym>
server dissconnected me often. I found that this was the
biggest time waster in the whole process. The timeout before
notifying me that the server wasn't responding, added to the
time it took me to notice and check that message, added to
the time it takes to reconnect, multiplied by a disconnect
every 20 to 60 minutes totaled many wasted hours. Not to
mention the time of waiting for the downloads. A program that
reconnects to an FTP server automatically would be a big help
in reducing the downloading time.</para>
</sidebar>
<para>
<application>ncftp</application>
has a feature to download files in the background:</para>
<tip>
<para>
<prompt>ncftp&#62;</prompt>
<command>bgget</command>
</para>
</tip>
<para>which would make the download easier and possibly faster
too.</para>
<sidebar>
<para>Upgrading would go smoother and quicker for a person
with more experience upgrading. For me, this was a discovery
effort, so there were many pitfalls for me. I am writing this
to help you avoid those pitfalls and so your experience
should go quicker than mine.</para>
</sidebar>
</sect2>
<sect2>
<title id="twobenifits">The benifits and costs of upgrading
this way</title>
<informaltable>
<tgroup cols="2" align="left">
<thead>
<row>
<entry align="center">Benifits</entry>
<entry align="center">Costs</entry>
</row>
</thead>
<tbody>
<row>
<entry>Downloading the packages is free.</entry>
<entry>But the big cost is the time it takes to
download and the space it takes to store them.</entry>
</row>
<row>
<entry>You don't have to buy the
<acronym>CD</acronym>
<!-- FIXME: extra white space -->
s.</entry>
<entry>The purchase price of the CD could contribute
towards future upgrades of the distribution.</entry>
</row>
<row>
<entry>Upgrading each package by hand gives you control
over your system. You'll have the opportunity to choose
which components you want and which you don't want. Not
all of the installation software available gives you
that much control.</entry>
<entry>That control requires some knowledge of what to
do and what not to do. (Be careful that anything that
you do can be undone, so that you can recover from your
mistakes.)</entry>
</row>
<row>
<entry>This control could be very helpful when you have
to squeeze Linux into a small harddisk or if you just
want to tailor Linux to your needs.</entry>
<entry>If you don't need the control, it is much easier
to get a commercial installer.</entry>
</row>
<row>
<entry>Upgrading one package at a time also gives you a
deeper understanding about the components of your
system and how they fit together.</entry>
<entry>
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</sect2>
<sect2>
<title id="twoassume">What I'm assuming about you.</title>
<itemizedlist>
<listitem>
<para>You'll need to know what rpm (Red Hat Package
Manager) is and have some basic experience using the
packages. (See
<xref endterm="rpmhowto" linkend="rpmhowto" />
<!-- FIXME : extra white space. -->
)</para>
</listitem>
<listitem>
<para>You have a working Linux with rpm installed.</para>
</listitem>
<listitem>
<para>If you are going to do the download, I assume that
you have more time on your hands than money (like me). Or
that you have a high speed Internet connection.</para>
</listitem>
<listitem>
<para>The upgrading will take some familiarity with Linux
and some knowledge of the what each package does. This
knowledge can be obtained from the package information, of
course. (See
<xref endterm="rpmtips" linkend="rpmtips" />
for how to show the summary information.)</para>
</listitem>
<listitem>
<para>You have to use that knowledge when choosing the
right packages to satisfy rpm dependencies. Normally these
will have similar names, which makes it simple to
do.</para>
</listitem>
<listitem>
<para>One solution probably won't work for everyone so
you'll have to be aware of what your doing and understand
why you're doing it.</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="distrothoughts">
<title>Some thoughts on distributions and upgrading</title>
<sect2>
<title id="twocharacteristics">Characteristics of a
distribution which would be a good choice for upgrading</title>
<itemizedlist>
<listitem>
<para>Current packages (so that your efforts in upgrading
are worth your while)</para>
</listitem>
<listitem>
<para>Well structured dependencies</para>
</listitem>
<listitem>
<para>Compatiblity with other distributions</para>
</listitem>
<listitem>
<para>Well structured grouping</para>
</listitem>
<listitem>
<para>Configured and tested packages</para>
</listitem>
<listitem>
<para>Packages configured for versitility and
security</para>
</listitem>
<listitem>
<para>Includes useful packages but skips unnessesary
ones</para>
</listitem>
<listitem>
<para>Easy and flexible installation program</para>
</listitem>
<listitem>
<para>A bootable CD with a Linux that can be used to do
maintainence on your system</para>
</listitem>
</itemizedlist>
<para>Of course, there are lots of other factors, each of which
will be important to different people. Many of the factors in
choosing a distribution are subjective. You'll have to weigh
them for yourself to decide which are important to you. I just
think that these were some relavant factors in regards to this
HOWTO.</para>
</sect2>
<sect2>
<title id="twoswitching">Switching distributions by upgrading
to new one</title>
<para>It's not impossible to upgrade from one distribution to
another, but it's very difficult. You'll have to deal with
missing files, unsatisfied dependencies, incompatable groupings
and incompatable package names.</para>
<para>It would be nice to be able to upgrade one disribution
with another, allowing you to see the advantages of a other
distributions. When building the rpms the builder has options
to which files are added, how the packagea are grouped, the
name of the package and the dependencies of the package. These
are some of the works that distibuters do. These will vary from
one distributor to another in quality and name. And so when you
try to use a package from one distributor to upgrade a package
of another distributor, you will find that it is not an exact
fit.</para>
</sect2>
</sect1>
<sect1 id="download">
<title>Download</title>
<sect2>
<title id="twopacklicense">Licensing of rpm packages</title>
<para>There are several different licenses that cover a
complete Linux OS. The most famous one is the GNU GENERAL
PUBLIC LICENSE (
<!-- FIXME: extra white space -->
<acronym>GPL</acronym>
<!-- FIXME: extra white space -->
) which allows the free distribution of derivative works of GPL
programs. (
<!-- FIXME: extra white space -->
<application>rpm</application>
itself is covered by this license. When used as a library it's
covered under the LGPL.) According to the GPL a derivative work
is, "a work containing the Program or a portion of it, either
verbatim or with modifications." Binary rpm packages are
derivative of the original program. If the original program was
covered by the
<acronym>GPL</acronym>
then so is the rpm package of it. Also, "Our General Public
Licenses are designed to make sure that you have the freedom to
distribute copies of free software (and charge for this service
if you wish), that you receive source code or can get it if you
want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these
things." This permits the free distribution of
<acronym>GPL</acronym>
software. Not all Linux software in a distribution is licensed
under the
<acronym>GPL</acronym>
<!-- FIXME: extra white space -->
, though.</para>
<para>So, this HOWTO refers to downloading GPL software.
Software that isn't covered under the GPL may require different
steps to respect those licensing requirments and those
differences will not be addressed at this time, for the sake of
simplcity. The easiest way to tell if a package is under the
GPL is to look for it being mentioned in the Copyright field of
the rpm information.</para>
</sect2>
<sect2>
<title id="twocandownload">Can linux be downloaded?</title>
<para>Yes, it can, if you have the disk space to keep all of
the files.
<acronym>FTP</acronym>
is a good download method.
<acronym>HTTP</acronym>
can be used also but is more difficult because it limits you to
downloading one file at a time. Here are some of the basics of
<application>ncftp</application>
and some pitfalls to avoid to make your downloading
easier.</para>
<para>A quick summary of some
<application>ncftp</application>
commands follows but see the info on
<command>ncftp(1)</command>
for all of the details of each command.</para>
</sect2>
<sect2>
<title id="twoncftpfeatures">ncftp features</title>
<para>The
<application>ncftp</application>
program is a nice tool. It can get the binary files off the
remote server and into the current working directory.
<itemizedlist mark="-">
<listitem>
<para>It is also possible to download files as a background
process using the bgget command allowing
<emphasis>unattended downloads</emphasis>
<!-- FIXME: extra white space -->
.</para>
</listitem>
<listitem>
<para>You can write download commands into scripts allowing
<emphasis>unattended downloads</emphasis>
<!-- FIXME: extra white space -->
. But I won't elaborate on that.</para>
</listitem>
<listitem>
<para>For files that weren't completely downloaded,
<application>ncftp</application>
is capable of resuming the download from where it left off
rather than starting the file from the beginning.</para>
</listitem>
<listitem>
<para>To abort a get command with two
<keycombo>
<keycap>Ctrl-C</keycap>
</keycombo>
keystrokes. This will stop your download and get you out of
ncftp quickly.</para>
</listitem>
<listitem>
<para>Use wild cards to get larger blocks of files.
<application>ncftp</application>
is also capable of getting directories, recursively.</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<sect2>
<title id="twotimesaver">Time savers: Skip unnecessary files
and tweak time-outs</title>
<para>You probably will not want to spend the time getting all
the files from the remote directory. For instance you can skip
any of the
<application>X</application>
servers that aren't meant for your video card. If you want to
save a big chunk of time and disk space you can skip the destop
packages but most home users won't want to do that. Home users
can skip many of the server packages, though. Base your choices
on the packages of your current system, but understand that
your distributor may have introduced some now and necessary
packages that cannot be skipped.</para>
<tip>
<para>Generate a list of your current system's packages with
one simple command:</para>
<para>
<prompt>$</prompt>
<command>rpm</command>
<parameter>-qa</parameter>
<filename>currentrpms</filename>
</para>
</tip>
<para>There's a way you can get ncftp to skip over some files
while getting files using a wild cards. Create an empty file in
your local directory which has the same name as the file that
you want to skip. Create a name for every file that you want to
skip. If you have the
<varname>auto-resume</varname>
disabled, when ncftp comes to that file during</para>
<para>
<prompt>ncftp&#62;</prompt>
<command>get</command>
</para>
<para>it will ask how you want to handle it. You can choose to
<computeroutput>[
<!-- FIXME: extra white space -->
<keycap>S</keycap>
<!-- FIXME: extra white space -->
]kip</computeroutput>
it.</para>
<para>To create the empty files in your local directory you can
first list the remote filesystem to see their exact
names.</para>
<para>
<prompt>ncftp&#62;</prompt>
<command>ls</command>
</para>
<para>To create an empty file with the same name:</para>
<para>
<prompt>$</prompt>
<command>touch</command>
<filename>FILE</filename>
</para>
<para>
<application>X</application>
allows you to highlight the file name and copy it with the
<mousebutton>middle mouse button</mousebutton>
<!-- FIXME: extra white space -->
. You'll have to prevent
<application>ncftp</application>
from completing the download of these files by disabling the
auto resume.</para>
<para>
<prompt>ncftp&#62;</prompt>
<command>set auto-resume no</command>
</para>
</sect2>
<sect2>
<title id="twotradeoff">Time saver trade off</title>
<para>If ncftp is set to automatically resume downloading then
it will defeat the purpose of creating the empty files. You
will not save any downloading time. So disable the auto resume
feature.</para>
<para>
<prompt>ncftp&#62;</prompt>
<command>set auto-resume no</command>
</para>
<para>The
<emphasis>trade-off</emphasis>
of setting
<application>ncftp</application>
in this way is that you'll have to tell
<application>ncftp</application>
to
<computeroutput>[
<!-- FIXME: extra white space -->
<keycap>S</keycap>
<!-- FIXME: extra white space -->
]kip</computeroutput>
each empty file, as they are encountered. It also means that
you will have to attend to the download process yourself in
order to answer these questions.</para>
<sidebar>
<para>It is up to you if you want use this to save download
time, or not. I chose to use it because there were several
dozen files that I wanted to skip. In the end, I'm not sure
if saving the download time was worth the effort.</para>
</sidebar>
</sect2>
<sect2>
<title id="twotimeouts">Local timeouts and Server
disconnects</title>
<para>The FTP server might have a tendency to kick you off
after every few files you download, even if there are only a
few users logged onto it. Sometimes you might even get
disconnected in the middle of a large (10-20 Megabyte)
file.</para>
<tip>
<para>That is when the resume feature of
<application>ncftp</application>
really comes in handy.</para>
</tip>
<para>These disconnects get very frustrating and time
consuming. When the server does kick you,
<application>ncftp</application>
will wait for a timeout before it informs you of the
disconnection. The variable which controls that timeout is
called
<varname>control-timeout</varname>
(isn't that clever of them?) I found that the default timeout
was way too long and slowing me down. This setting delays how
long
<application>ncftp</application>
will take before announcing that the server wasn't responding.
You'll probably want to decrease both your
<varname>connect-timeout</varname>
and
<varname>control-timeout</varname>
in order to speed up the download process. The more reliable
your connection with the server then the smaller you can make
them. As you download each chunk of files, turn them down
slowly and pay attention to see if decreasing your timeout
makes your connection less reliable. If that happens then you
have gone too low.</para>
<tip>
<para>See the
<application>ncftp</application>
man pages for descriptions of the timeout variables, there
are 3 of them.</para>
</tip>
<sidebar>
<para>My timeout variables are set as so:
<simplelist>
<member>connect-timeout : 20</member>
<member>control-timeout : 10</member>
<member>xfer-timeout : 3600</member>
</simplelist>
</para>
</sidebar>
</sect2>
</sect1>
<sect1 id="partitions" xreflabel="Partitions">
<title>Partitions</title>
<sect2>
<title id="twoconsidermore">You've got one partition but
consider making more.</title>
<para>You may find as you're upgrading that having a separate
partition for backups can be very handy. You can choose to
stick with just one partition for Linux but consider the
possible flexibility that adding one or more spare partitions
might give you when upgrading.</para>
<para>A spare partition can perserve backups during an
installation. Backup the /etc and /home directories for
example. Or it can hold your downloaded rpm packages.
<application>mount</application>
it to a temporary point while restoring the backups. After
restoring from the backups, that partition can be erased and
remounted at a more permanent point, integrating it into the
running system. If the partition is large enough to fit both
the backups and the files that are normally installed in that
mount point, then it can be mounted as normal during
installation and won't need to be erased. This was my
case.</para>
<para>If you decide to create a spare partition for backups you
have the choice of making one big partition or several smaller
ones. Installing on one partition is simpler than multiple
ones. If you only use one partition now, it will be possible to
divide the partition into smaller partitions after the
installation. But non-destructive repartitioning (programs like
<application>fips</application>
or
<application>Partition Magic</application>
<!-- FIXME: extra white space -->
) will be necessary if that partition has data on it.</para>
<para>Having one, large spare partition is convienient because
it can fit all of the backup data in one place.
<emphasis>But</emphasis>
that can have the disadvantage of being wastefully large when
trying to integrate it into your new installation. For instance
with Linux fully installed on the other partition, where would
you mount the spare partition? The big mount points like
<filename>/usr</filename>
and
<filename>/home</filename>
<!-- FIXME: extra white space -->
, are already be installed and mounted. What other directories
need a large partition?</para>
<para>On the other hand, multiple partitions can give some
flexibility during the backup and installation that a large one
dosen't have. It will be more complicated to break up your
backup data across several spare partitions but when the
partitions are remounted you'll have more options of where to
mount them. Mount the spare partitions as extra swap space,
<filename>/opt</filename>
<!-- FIXME: extra white space -->
,
<!-- FIXME: extra white space -->
<filename>/etc</filename>
<!-- FIXME: extra white space -->
, or many other of the smaller directories. It will be easier
to mount the spare partitions at these points since they're a
little less crucial to a running system as directories like
<filename>/</filename>
or
<filename>/usr</filename>
<!-- FIXME: extra white space -->
. If you find that you didn't give some mount point a big
enough partition and you'd like to give it some more space then
a small spare partition can be mounted somewhere under that
original mount point, in order to expand it.</para>
<sidebar id="expandrootpartition"
xreflabel="Expanding the root partition">
<para>For instance, I had
<filename>/</filename>
mounted on too small a partition. It ran out of space a
couple of times after the upgrade. But I had a spare
partition which was mounted to a temporary point called
<filename>/extra</filename>
<!-- FIXME: extra white space -->
. When I saw that the
<filename>/var</filename>
directory was the cause of the
<filename>/</filename>
partition getting filled, I was able to mount the spare
partition as
<filename>/var</filename>
on the seperate partition. That freed up some space on the
<filename>/</filename>
partition and gave the new
<filename>/var</filename>
partition more room to grow.</para>
</sidebar>
<para>It is up to you if you want to give Linux one partition
for convienience or if you want to try multiple partitions for
flexiblity. There isn't a single correct answer for all
systems</para>
<tip>
<para>There is a detailed HOWTO (
<!-- FIXME: extra white space -->
<xref endterm="partitionhowto" linkend="partitionhowto" />
<!-- FIXME: extra white space -->
) on partitioning if you'd like to learn more about them and
thier use.</para>
</tip>
<sidebar>
<para>My situation wasn't ideal but it will be a good example
to explain some ideas. While upgrading my Linux I made a
mistake that completely prevented my kernel from booting. The
mistake was improperly upgrading the
<application>glibc</application>
libraries. As a result of that I had to re-install my old
version of Linux before being able to use the upgrade rpms. I
was lucky to have a seperate partition (my Windows partition)
to keep the downloaded rpms while I re-installed Linux. The
spare partition saved me from having to destroy over 600
Mbytes of downloads. Because of that spare partition, I was
able to re-partition, re-format and re-install Linux without
loosing any of the downloaded rpms.</para>
<para>When I installed, I was so pleased at the value of
having an extra partition that I decided to make several
partitions on the Linux side of my harddrive to give me the
most flexibility for the next time that I
re-installed.</para>
</sidebar>
</sect2>
<sect2>
<title id="twopartitiontools">Partitioning tools</title>
<sidebar>
<para>I chose to create several partitions. I'll explain what
partitions I made and my reasons for making them. Read on and
decide for yourself if you think that my examples are are
worth trying on your system.</para>
</sidebar>
<para>When you have multiple partitions in Linux the partitions
should be appropriatly sized for the directory that they'll be
mounted as. You can estimate those sizes based on my setup, but
it would be better if you based those sizes on your existing
installation. To check the size of a directory issue the
command:</para>
<para>
<prompt>$</prompt>
<command>du</command>
<parameter>-sh</parameter>
<filename>[FILE]</filename>
</para>
<para>One possible approach is to use one (or more than one)
partition for holding your backup data. Use the remaining ones
to complete the Linux installation. This, of course, assumes
that your harddrive is large enough to fit all of this. Check
your installation requirements to get an idea of how much space
you'll need to install Linux. Compare that to your harddrive
space devoted to Linux and maybe you'll find that the
difference leaves you enough room to backup on the same
harddrive. This is a very convienent way to temporarily backup
during an upgrade or install.</para>
<sidebar>
<para>Half of my 8 gigabyte drive is devoted to Windows and
the other half to Linux. The first primary partition (
<!-- FIXME: extra white space -->
<medialabel>/dev/hda1</medialabel>
<!-- FIXME: extra white space -->
) was used to backup the rpm packages, when first downloading
them. While re-installing, I also used one of the Linux
partitions for backup. The second primary partition (
<!-- FIXME: extra white space -->
<medialabel>/dev/hda2</medialabel>
<!-- FIXME: extra white space -->
) reserves the physical space for the logical partitions.
Those logical partitions are the ones that are mounted by
Linux. This second primary partition is never mounted
directly.</para>
</sidebar>
<tip>
<para>Use
<application>fdisk</application>
or your distribution's installation program, to display and
manipulate the partition information.</para>
<para>
<prompt>#</prompt>
<command>fdisk</command>
<medialabel>DISK</medialabel>
</para>
<para>Run
<application>fdisk</application>
as root and display the partition information.</para>
<para>
<prompt>Command (m for help):</prompt>
<command>p</command>
</para>
<para>Quit the program without writing any changes.</para>
<para>
<prompt>Command (m for help):</prompt>
<command>q</command>
</para>
</tip>
<tip>
<para>The mount point information can be obtained from the
file
<ulink url="file:/etc/fstab" type="local file">
/etc/fstab</ulink>
or with
<application>mount</application>
using no arguments.</para>
<para>
<prompt>$</prompt>
<command>mount</command>
</para>
</tip>
<tip>
<para>Check how much free space is on your partitions.</para>
<para>
<prompt>$</prompt>
<command>df</command>
<parameter>-h</parameter>
</para>
</tip>
<caution>
<para>Whichever partition(s) hold your backups, make sure
that you do not reformat or resize it during installation,
those would destroy your backups.</para>
</caution>
<tip>
<para>You can use
<application>top</application>
or
<application>kpm</application>
to monitor how much swap space your system uses.</para>
</tip>
</sect2>
<sect2>
<title id="twopartitionexample">A partitioning example</title>
<sidebar>
<table id="partitiontable" xreflabel="Partition Table">
<title>Here is how my logical partitions are mounted their
sizes:</title>
<tgroup cols="5">
<thead>
<row>
<entry>Partition</entry>
<entry>Mount point</entry>
<entry>Size</entry>
<entry>Used space</entry>
<entry>Used percentage</entry>
</row>
</thead>
<tbody>
<row>
<entry>/dev/hda5</entry>
<entry>/home</entry>
<entry>
<property>963 Mbytes</property>
</entry>
<entry>
<property>596 Mbytes</property>
</entry>
<entry>65%</entry>
</row>
<row>
<entry>/dev/hda6</entry>
<entry>/boot</entry>
<entry>
<property>15.9 Mbytes</property>
</entry>
<entry>
<property>3.32 Mbyes</property>
</entry>
<entry>22%</entry>
</row>
<row>
<entry>/dev/hda7</entry>
<entry>/usr</entry>
<entry>
<property>1.97 Gbytes</property>
</entry>
<entry>
<property>1.18 Gbytes</property>
</entry>
<entry>63%</entry>
</row>
<row>
<entry>/dev/hda8</entry>
<entry>swap (not mounted)</entry>
<entry>
<property>64.2 Mbytes</property>
</entry>
<entry>
<property>27.0 Kbytes</property>
</entry>
<entry>4.2%</entry>
</row>
<row>
<entry>/dev/hda9</entry>
<entry>/var</entry>
<entry>
<property>64.4 Mbytes</property>
</entry>
<entry>
<property>44.8 Mbytes</property>
</entry>
<entry>74%</entry>
</row>
<row>
<entry>/dev/hda10</entry>
<entry>/opt</entry>
<entry>
<property>884 Mbytes</property>
</entry>
<entry>
<property>352 Mbytes</property>
</entry>
<entry>42%</entry>
</row>
<row>
<entry>/dev/hda11</entry>
<entry>/</entry>
<entry>
<property>135 Mbytes</property>
</entry>
<entry>
<property>59.8 Mbytes</property>
</entry>
<entry>47%</entry>
</row>
</tbody>
</tgroup>
</table>
</sidebar>
<para>This table gives you an idea of how big Linux is with
XFree86, KDE 2 and lots of other goodies. Check your
distribution's size requirements to find out how much space it
takes up. I'll quickly discuss each of these partitions so that
you can understand them and you can come up with your own
strategy.</para>
</sect2>
<sect2>
<title id="twowhypartitions"
xreflabel="Why all of those partitions?">Why all of those
partitions?</title>
<para>My
<filename>/home</filename>
partition was used for backup during installation. During
installation this can be mounted as the normal
<filename>/home</filename>
directory. This is the directory that holds all of the user
accounts and the users' personal data. Make sure that none of
the existing directories on that partition have the same names
as any of the users that you will be adding during
installation. If they have the same name then your data could
get overwritten. Also don't name any of the directories as
<filename>/home/httpd</filename>
which belongs to
<application>apache</application>
<!-- FIXME: extra white space -->
. Once mounted, the upgrade process can start from these
backups. Use temporary names for the backups of the user
accounts and allow the installation to create new users.
Restore the data to the new user directories after upgrading
the rest of system.</para>
<para>The
<filename>/boot</filename>
partition holds the kernel image and associated files and
possibly the boot loader (
<!-- FIXME: extra white space -->
<application>grub</application>
<!-- FIXME: extra white space -->
). It tends to be small and can be useful for positioning the
kernel below cylinder 1024 on large hard disks in order to
avoid the well documented BIOS limition which impedes booting a
kernel image located at or above that cylinder. This partition
will be too small to be much use for backups.</para>
<para>The
<filename>/usr</filename>
partition will be the largest because it holds the majority of
your programs. It has the size to be useful for backup but
since so much will be placed here during installation, it might
be complicated to figure out how much space to leave for the
programs. Of course, if this partition is larger than the total
amount specified by the installation requirments than it should
be fine to use the remaining space for backup since this
directory will surely be smaller than that
specification.</para>
<para>The swap partition and the
<filename>/extra</filename>
partition were sized and positioned very specifically. With 64
Mbytes of RAM I wanted a swap partition that could be as much
as double that size. That would mean that I'd need about a 128
Mbyte swap file. In Linux kernel verion 2.1 128 Mbytes is the
upper limit of the size of a single swap partition but that
limit has been raised since then. My sytem dosn't usually use
much swap space though, so I broke that in to two partitions.
One was made into a swap partition and the other was made
mountable by formatting it as an ext2. This gave me the option
of later changing the second partition to a swap partition, but
to be able to use it for file space for now.</para>
<note>
<para>Note: The
<filename>/extra</filename>
was remounted as
<filename>/var</filename>
as explained in
<xref endterm="expandrootpartition"
linkend="expandrootpartition" />
and that is why
<filename>/extra</filename>
dosen't appear in the previous table.</para>
</note>
<sidebar>
<para>I made the
<filename>/extra</filename>
and swap partitions about 64 Mbytes a piece. If I found that
I needed more swap space I could convert the
<filename>/extra</filename>
partition to a swap partition. For the time being, I can
mount the
<filename>/extra</filename>
partition and use it for storage. Finally, I also positioned
the
<filename>/extra</filename>
between the
<filename>/</filename>
and
<filename>/opt</filename>
partitions so that the
<filename>/extra</filename>
partition could be combined with either one of those
partitions to expand their size.</para>
</sidebar>
<para>The
<filename>/opt</filename>
partition holds some more programs. And in that way, it has the
same problems in using it for a backup partition as the
<filename>/usr</filename>
partition. You'll need to have and idea of how much space the
upgraded programs will take up and the remaining space is
available for backup data. Contributing to the 352 Mbytes (as
shown in the table above. See
<xref endterm="partitiontable" linkend="partitiontable" />
<!-- FIXME: extra white space -->
.) of my
<filename>/opt</filename>
partition are
<application>acroread-4.0</application>
<!-- FIXME: extra white space -->
,
<application>KDE</application>
<!-- FIXME: extra white space -->
,
<application>KDE 2</application>
<!-- FIXME: extra white space -->
and
<application>rvplayer5.0</application>
<!-- FIXME: extra white space -->
.</para>
<note>
<para>Note that if you have
<application>Netscape</application>
it also gets installed in
<filename>/opt</filename>
<!-- FIXME: extra white space -->
.</para>
</note>
</sect2>
<sect2>
<title id="twofreshinstall">Starting with a fresh
install</title>
<orderedlist>
<title>What are the good reasons for erasing your Linux and
starting with a fresh install?</title>
<titleabbrev>Why perform a fresh install?</titleabbrev>
<listitem>
<para>Your distribution may want you to.</para>
</listitem>
<listitem>
<para>Linux has a mess of programs and files that you don't
want to keep and would love an easy way to get rid of
them.</para>
</listitem>
<listitem>
<para>Installing on a new harddrive.</para>
</listitem>
<listitem>
<para>You've got no files that you care about
loosing.</para>
</listitem>
<listitem>
<para>You don't have time to do anything more than the
minimum effort and your backups are complete and
up-to-date.</para>
</listitem>
</orderedlist>
</sect2>
<sect2>
<title id="twosummary">Summary</title>
<para>In conclusion, there are many possible ways of
re-arranging your data between various partitions. The
advantage this gives is to keep an undisturbed copy of the data
while doing a complete install. This was just one possible
scheme and gives you an idea of how much space is needed for
Linux in the various directories. Gathering this type of
information from your existing system before installing will be
very useful if you decide to re-partition the drive.</para>
<caution>
<para>If you repartition a drive that has data in one or more
partitions make sure that you don't change the size of any of
the partitions holding data. If you do the data will be
destroyed with any standard partitioning program like
<application>fdisk</application>
<!-- FIXME: extra white space -->
. If you accidentally change the size of a partition which is
holding backup data, don't panic. All you have to do is
either quit the application, or have it re-read the
partitioning information from the disk. In
<application>fdisk</application>
quit without writing and start over again.</para>
<para>
<prompt>Command (m for help):</prompt>
<command>q</command>
</para>
</caution>
</sect2>
</sect1>
<sect1 id="installprecautions">
<title>Prepare for trouble, before installing</title>
<sect2>
<title id="twolibraryupgrade">The dangers of upgrading the base
libraries</title>
<para>The kernel is dependant on the GNU libraries. If the
libraries are removed then the running kernel can't access
them. The kernel will stop running. That is a bad thing.
<emphasis>Do not erase, uninstall, upgrade or delete the GNU
libraries!</emphasis>
At least not until you're certain that the kernel is using the
upgraded libraries. I'll explain this more in the next
section.</para>
</sect2>
<sect2>
<title id="twoupgradevsinstall">'rpm -U' verses 'rpm
-i'</title>
<para>
<itemizedlist>
<title>When
<application>rpm</application>
upgrades (
<parameter>-U</parameter>
) a package it will :</title>
<listitem>
<para>Compare the version of the rpm file with the
version of the corresponding installed package to be sure
that the rpm file is more recent. There are other checks
that it runs for file conflicts, dependencies,
etc.</para>
</listitem>
<listitem>
<para>Install the new package files and register the new
package name.</para>
</listitem>
<listitem>
<para>Remove the old package files and the package name
from the rpm database.</para>
</listitem>
</itemizedlist>
</para>
<para>
<itemizedlist>
<title>When
<application>rpm</application>
installs (
<!-- FIXME : extra white space. -->
<parameter>-i</parameter>
<!-- FIXME : extra white space. -->
) a package it will :</title>
<listitem>
<para>Do the same checks for installed versions, file
conflicts, dependencies, etc.</para>
</listitem>
<listitem>
<para>Install the new package files and register the new
package name.</para>
</listitem>
</itemizedlist>
</para>
<para>You'll notice that the main difference is that upgrading
removes the old package but installing dosen't try to remove an
old package. Install assumes there isn't a package installed on
your system which corresponds to this new package. That is an
important difference when upgrading crucial packages that your
system is using.</para>
<para>Normally you will be upgrading the various packages. But
for crucial packages, like the base GNU libraries installing (
<!-- FIXME : extra white space -->
<parameter moreinfo="none">-i</parameter>
<!-- FIXME : extra white space -->
) a package allows the old package to remain. This is necessary
when your running system is dependant on the files of the old
package.</para>
<para>When you install a new package, and there is an old one
on your system,
<application>rpm</application>
will not notice the old package in the database but it will see
the files of the package.
<application>rpm</application>
will complain about file conflicts. The complaints mean that
some (or all) of the files of the new package have the same
name and location as the files of the old, running package.
<application>rpm</application>
won't install the new package as long as it's detecting this
error. You can use
<parameter moreinfo="none">--force</parameter>
to have rpm ignore the error, but be careful if you do. Be sure
that
<application>rpm</application>
reports no other errors before forcing the install. Correct all
other errors before forcing. Once forced to install,
<application>rpm</application>
will overwrite the old files with the new ones. Since this
dosen't delete the old files, but overwrites them instead, your
system can still access the files and still run. Also, when
querying,
<application moreinfo="none">rpm</application>
will accurately report to you that both the old and the new
packages are installed. The fact that the database has both
versions listed is harmless to the database. But make a note of
the redundant packages in case you want to remove the old one
later.</para>
<para>There is a possible problem with this technique though.
The new files might have some compatibility bugs with the
running system. I can't tell you how to avoid them. This is a
risk that you will be taking with this technique. The
advantages of this technique is that you're using the running
system to upgrade itself and the system may not need to be shut
down.</para>
</sect2>
<sect2>
<title id="twokernelupgrade">The dangers of upgrading the
kernel</title>
<para>Pretty much the same as the dangers of upgrading the GNU
libraries. You shouldn't remove a running kernel's files. That
would stop it from running. Also, overwriting the existing
files with the upgraded ones runs the risk of
incompatibilities. But there's no way to avoid that risk if you
want to upgrade a running kernel. Your distribution may have
created new directories or new filenames in order to avoid
overwriting. But the kernel is resident in memory and that
makes it easier to upgrade than the libraries. You can upgrade
the binary kernel package, once all of it's dependancies have
been installed or upgraded properly.</para>
</sect2>
<sect2>
<title id="twoavoidmistakes">Ways to avoid mistakes</title>
<itemizedlist>
<listitem>
<para>Test an
<application>rpm</application>
comamnd with
<parameter>--test</parameter>
before you perform one that might be dangerous. Look for
any error messages, understand why they're being generated
and fix them before issuing the
<application>rpm</application>
command.</para>
</listitem>
<listitem>
<para>Make sure that downloaded packages are fully
downloaded once they're finished downloading. The easiest
way to check this is to compare the file size on the server
with the file size on your harddrive. Or you could use
<parameter moreinfo="none">-K</parameter>
to have
<application>rpm</application>
do it's more secure and reliable checks. If you've got
<application>PGP</application>
set up right, do the full checks or use
<parameter moreinfo="none">--nopgp</parameter>
to skip the
<application>PGP</application>
check if you don't. Verifying that the package downloaded
correctly for the crucial packages (the base packages such
as the kernel packages and the GNU libraries) is an
important safeguard. A bad package which installs most of
the files, but not all of them, can really mess up your
system. (That is possible with rpm packages.) Checking is
not as necessary for the less crucial packages though. So
you don't need to bother for all packages.</para>
</listitem>
<listitem>
<para>For some packages it might be a good idea to make
backup copies of the files before upgrading. If the upgrade
dosen't work, these backups can be used to restore without
the need of
<application>rpm</application>
<!-- FIXME: extra white space -->
. This won't restore the rpm database, of course, but it
will get the program running again. The times when you
might need this, as stated before, are the crucial base
packages and also
<application>rpm</application>
itself.</para>
</listitem>
<listitem>
<para>Keep track of what your doing. Knowing your progress
in downloading and upgrading helps you to avoid silly
mistakes such as downloading a package twice or missing a
package that you thought you had upgraded but haven't even
downloaded. There are lots of packages in any
distribution.</para>
</listitem>
</itemizedlist>
<tip>
<para>If you ever want to backup your rpm database it's
located at
<ulink url="file:/var/lib/rpm">/var/lib/rpm</ulink>
<!-- FIXME: extra white space -->
.</para>
</tip>
<sidebar>
<para>I have 576 packages installed on my system. Keeping
track of all of them in your head is complicated. Having some
written records of your progress will help ease your
burden.</para>
</sidebar>
</sect2>
<sect2>
<title id="twokeepingtrack">Keeping track of your
progress</title>
<para>rpm can generate a list of the installed packages for you
by querying all the packages.</para>
<para>
<prompt>$</prompt>
<command moreinfo="none">rpm</command>
<parameter moreinfo="none">-qa</parameter>
<parameter>|</parameter>
<command>sort</command>
<parameter>&#62;</parameter>
<!-- FIXME : greater than isn't htmling -->
<filename>currentrpms</filename>
</para>
<para>Compare that with a list of the upgrade rpms. Generate
the upgrade list by first, changing to the drectory where you
put the upgrade rpms, then issue this command to make a list.
<application>sed</application>
removes the '.i386.rpm' file extensions.</para>
<para>
<prompt>$</prompt>
<command>ls</command>
<parameter>-1</parameter>
<parameter>*.rpm</parameter>
<parameter>|</parameter>
<command>sort</command>
<parameter>|</parameter>
<command>sed</command>
<parameter>-e</parameter>
<parameter>"s/\.i386\.rpm.*//"</parameter>
<parameter>&#62;&#62;</parameter>
<filename>upgraderpms</filename>
</para>
<para>Finally, to make it easier to compare those two sorted
lists, use
<command moreinfo="none">diff</command>
to highlight the differences.</para>
<para>
<prompt>$</prompt>
<command>diff</command>
<parameter>-u</parameter>
<filename>currentrpms</filename>
<filename>upgraderpms</filename>
<parameter>|</parameter>
<command moreinfo="none">less</command>
</para>
<para>Basically, packages with a '+' before the name are files
that are not installed yet. Packages with a '-' are installed
on the system. Packages with a space character are just
contextual information.</para>
<para>While that gives you a nice written record of your
progress, it is cumbersome to read.
<application>Kpackage</application>
is a tool that arranges all of the packges into a catorgized
tree. It can sort out the upgrade packages for you, giving you
a convienient, expandable tree to look at. I used both tools
while upgrading.</para>
</sect2>
<sect2>
<title id="twootherproblems">Other problems, beyond your
control.</title>
<para>"Ooops! After that upgrade, program
<application>
<replaceable>foo</replaceable>
</application>
won't run any more."
<application>
<replaceable>foo</replaceable>
</application>
could be the program that you just upgraded or one that you
didn't realize was related to that upgraded program.</para>
<para>The latter reason is because frontend programs are built
to rely on other backend programs to do some of the work.
Libraries are always used as a backend of another program. So,
when upgrading backend programs or libraries, the frontend
program may stop working because of incompatibilities between
the old frontend and the new backend.</para>
<para>On the other hand, you shouldn't get that problem when
upgrading frontend programs because
<application>rpm</application>
will give you dependency errors as you try to upgrade. The
dependencies tell you which backends and libraries the frontend
is dependant on. But since the backend programs don't need the
frontends in order to be complete, there are very few
dependencies errors when upgrading backends.</para>
</sect2>
<sect2>
<title id="tworecover">Ways to recover from mistakes</title>
<orderedlist>
<listitem>
<para>If upgrading a backend or library causes a frontend
to stop working, the best solution, obviously, is to
upgrade the front end.</para>
</listitem>
<listitem>
<para>This might not always be possible, though. There may
be so many dependencies to satisfy, before upgrading the
frontend, that it will take you too long to complete them
all before getting your program back online. It may be
worth it to downgrade back to the orignal version of the
backend so that you can get the frontend program working
immediately. This can be done by either :</para>
<para>
<command>rpm</command>
<parameter>-U</parameter>
<parameter>--force</parameter>
<filename>&#60;packagenames&#62;</filename>
</para>
<para>
<command>rpm</command>
<parameter>-U</parameter>
<parameter>--oldpackage</parameter>
<filename>&#60;packagenames&#62;</filename>
</para>
</listitem>
<listitem>
<para>If you can't upgrade nor downgrade, go to your
backups. If you made backups of the actual files that were
a part of the old pacakge you can now use a simple
<application>cp</application>
command to restore the program. It can be complicated to
get all of the files of a package backed up. But even if
you miss a few, restoring might get your program running
well enough to function for your needs. You should be able
to use an rpm upgrade (or maybe even a downgrade) later, to
get all of the files matching the database.</para>
</listitem>
<listitem>
<para>In the worst case, if the crippled program was so
crucial that you can't run your Linux system anymore,
you'll need to run an alternate system. Boot up your spare
Linux (
<xref endterm="progtomsrlbt" linkend="progtomsrlbt" />
or
<!-- FIXME: the above to xrefs, link to the top of the HTML
page and not to the proper section. Their target anchor is missing. -->
<xref endterm="proginstallcd" linkend="proginstallcd" />
)
<!-- FIXME: extra white space -->
<!-- FIXME: the above to xrefs, link to the top of the HTML
page and not to the proper section. -->
and try to use that to restore your backups or rpm
packages.</para>
</listitem>
</orderedlist>
</sect2>
</sect1>
<sect1 id="upgrade">
<title>Upgrade the packages</title>
<sect2>
<title id="twoupandrunning">Does everybody have their Linux up
and running?</title>
<para>Let's just get on the same page now. There have been many
paths you could have taken to get to this point. Now, all of
the partitioning of the harddrive is done. You have a working
Linux system running. The Linux should be on that harddrive.
That Linux should have a working copy of
<application>rpm</application>
with its database of packages up-to-date, relative to the Linux
system. Your favorite GUI wrappers, frontends or replacements
to
<application>rpm</application>
are helpful and convienient to have at this point. (See
<xref endterm="othertools" linkend="othertools" />
for some of your options.) Backups are on spare partitions or
removable media, are up-to-date and are safe.</para>
<para>You've obtained all of the packages needed to perform the
upgrade. If you're still in the process of downloading them,
you'll need to have at least the base packages and all of their
dependencies. The web of dependancies can be complicated and
surprising. To be safe, obtain as much as you can before
starting the upgrade process. You don't want to be caught
without a necessary package in the middle of a crucial upgrade,
or your system might be harmed.</para>
</sect2>
<sect2>
<title id="twodeterminebase">Determining which packages are the
base packages</title>
<para>Start by upgrading the base packages. Which packages are
they? There are several ways to identify them, but their names
will vary, depending on which distribution you're working
with.</para>
<orderedlist>
<listitem>
<para>Base GNU/Linux system libraries:
<simplelist type="inline">
<member>glib</member>
<member>glibc</member>
<member>libc5 (for backward compatibility)</member>
</simplelist>
</para>
</listitem>
<listitem>
<para>the Linux kernel's dependencies:
<simplelist type="inline">
<member>modutils</member>
<member>acpid</member>
<member>kernel headers</member>
<member>common kernel source</member>
<member>processor specific source packages (i386, Sparc,
Alpha, etc.)</member>
<member>etc.</member>
</simplelist>
</para>
</listitem>
<listitem>
<para>the Linux kernel:
<simplelist type="inline">
<member>linux</member>
<member>kernel</member>
<member>linux-kernel-binary</member>
<member>etc..</member>
</simplelist>
</para>
</listitem>
</orderedlist>
<para>Start by checking the Group field of the
<application>rpm</application>
information. Look for a string that indicates the system's base
libraries and base programs. For example, Caldera's groups look
like this :
<simplelist type="vert">
<member>"Group : System/Library"</member>
<member>"Group : System/Base"</member>
<member>"Group : System/kernel"</member>
<member>"Group : Base/Kernel"</member>
<member>"Group : System/Shell"</member>
</simplelist>
Red Hat's (Version 5.2) corresponding group names are :
<simplelist type="vert">
<member>"Group : Libraries "</member>
<member>"Group : Utilities/System"</member>
<member>"Group : Development/Tools"</member>
<member>"Group : Daemons"</member>
<member>"Group : Development/Libraries"</member>
<member>"Group : Base"</member>
<member>"Group : Shells"</member>
</simplelist>
These will include
<simplelist type="inline">
<member>the kernel packages</member>
<member>the GNU glib libraries</member>
<member>kernel-headers</member>
<member>the old libc package</member>
<member>glibc</member>
<member>etc</member>
<!-- FIXME: extra white space -->
</simplelist>
. Make sure you have all of the kernel dependencies satisfied
before you start installing anything.</para>
<tip>
<para>Check that the dependencies are satisfied by "test"
installing the kernel rpms first with the
<parameter>--test</parameter>
parameter. This will report back to you if you're missing any
dependencies.</para>
</tip>
<para>Here are the requirements listed in the Changes from
kernel 2.4.17 to give you an idea of what packages support the
kernel. Generally, these are upgraded before the kernel is.
<screen format="linespecific">
&#111; Gnu C 2.95.3 # gcc --version
&#111; Gnu make 3.77 # make --version
&#111; binutils 2.9.1.0.25 # ld -v
&#111; util-linux 2.10o # fdformat --version
&#111; modutils 2.4.2 # insmod -V
&#111; e2fsprogs 1.25 # tune2fs
&#111; reiserfsprogs 3.x.0j # reiserfsck 2&#62;&amp;1|grep reiserfsprogs
&#111; pcmcia-cs 3.1.21 # cardmgr -V
&#111; PPP 2.4.0 # pppd --version
&#111; isdn4k-utils 3.1pre1 # isdnctrl 2&#62;&amp;1|grep version</screen>
<!-- FIXME : tidy always messes up this text -->
</para>
</sect2>
<sect2>
<title id="twostaycautious">Stay cautious</title>
<para>Once the base libraries, the kernel dependencies and the
kernel are upgraded you've gotten through the most risky part
of the upgrade. But not the only risk. There are other crucial
packages to your system like the
<application>libz</application>
<!-- FIXME: extra white space -->
,
<application>bash</application>
and
<application>ncurses</application>
<!-- FIXME: extra white space -->
. Be sure to satisfy any dependencies and solve any errors for
these or your prompt will not function and you may not be able
to boot. The system initialization scripts are crucial, also.
And so are the base libraries for
<application>KDE</application>
along with the
<application>Qt</application>
libraries.
<application>X</application>
has its crucial dependancies too.</para>
<para>So, in general, be aware of your packages. Try to read
the package information before upgrading it, so that you can
have an idea of how cautious you need to be while upgrading
it.</para>
</sect2>
<sect2>
<title id="twoignoretar">rpm ignores tar balls</title>
<para>
<application>rpm</application>
has some smarts built into it, but sometimes it is not smart
enough. If you have any tar balls installed that serve as a
dependency to an rpm package,
<application>rpm</application>
will not see those files and will give you dependancy errors.
In that case, you do have the files that rpm is looking for
installed but since they weren't entered in the rpm database,
<application>rpm</application>
ignores the files. To work around this, you'll have to have
<application>rpm</application>
ignore dependancies
<parameter>--nodeps</parameter>
or even
<parameter moreinfo="none">--force</parameter>
if it keeps complaining.</para>
</sect2>
<sect2>
<title id="twofullspeed">Full speed ahead</title>
<para>Once you get through the base packages things will start
to go quicker. Soon you get in the habit of how cautious you
need to be. As things get upgraded, you'll start to see the
gratification of new features and new looks to your
applications.</para>
</sect2>
</sect1>
<sect1 id="restore">
<title>Restoring and Cleaning up</title>
<sect2>
<title id="twomountbackup">Restoring and mounting the backup
directory</title>
<para>If you were using a spare partition for backup of rpm
packages and system files it is now time to mount that into the
system.</para>
<procedure>
<step>
<para>Choose the mount point that you planned on using from
the "
<!-- FIXME: extra white space -->
<xref linkend="twowhypartitions" />
<!-- FIXME: extra white space -->
" section.</para>
</step>
<step>
<para>That mount point will already exist as a directory
with files in it as a part of the running system. Because
of this you'll need to integrate the new files with your
old, backed up files. Some old files many need to be
deleted. Some old files need to be merged with the new
files. And, some new files many need to be deleted.</para>
<para>It will take some work to merge old configuration
files with new ones. For some packages though, there will
be no work in integrating the configuation files because
the file format hasn't changed in the new version.</para>
</step>
<step>
<para>There are some more configuration files to merge once
you're done with those.
<application>rpm</application>
has a feature of saving backup copies of some of the
configuration files that it replaces. It will do this when
it can merge the files itself. In that case it will save
the original file by appending ".rpmsave" to the file name.
Then it installs the new configuration file. You should
<application>locate</application>
all of the files with that string at the end of the name,
and merge them with the new configuration file.</para>
</step>
<step>
<para>Once the configuration files are merged, test out the
new mount point by mounting it. The system may be using
that mount point and not allow you to re-mount it. In that
case, you'll have to skip to the next step.</para>
</step>
<step>
<para>Make a backup of
<filename>/etc/fstab</filename>
to restore in case this modification dosen't work
correctly.</para>
<para>
<filename>/etc/fstab</filename>
will have to be modified to make the new mounting
permanent. Reboot after modifying it to make sure that it
is working correctly.</para>
</step>
</procedure>
<note>
<para>While all of this merging seems daunting, don't loose
heart. In general, the configuration files which haven't been
changed since they were installed shouldn't need to be merged
by hand. The only time they'll need to be merged by hand is
when there are major changes to their format, done by the
program author. That shouldn't happen often.</para>
<para>But if there were configuration files that you made
large changes too they might need to be merged.</para>
</note>
</sect2>
<sect2>
<title id="twooldpackages">Old packages</title>
<para>Once all of the rpm files have been used to upgrade, you
might find that there are some installed packages that weren't
upgraded. This is because they were a part of the old
distribution's version but not the new version. Since they were
not necessary by the new distribution they shouldn't be
necessary for your system. You can remove them if they aren't
packages that you use.</para>
<para id="tipupgraderedundancy"
xreflabel="Upgrade redundancy tip">You may also find some
duplicate packages installed, which only differ by version
number. This sometimes happens when
<application>rpm</application>
is forced (
<!-- FIXME: extra white space -->
<parameter>--force</parameter>
)
<!-- FIXME: extra white space -->
while installing or upgrading. The database is accurate, saying
that there are duplicate packages, and this isn't a problem for
your system or the
<application>rpm</application>
database. Basically the newer package overwrote the common
files between the two versions of the packages. So you'll wind
up with all of the new versions of the files anyway.</para>
<para>Eventually you will probably want to correct the
reduncancy, though, in order to save harddrive space and avoid
complicating the dependancies.
<application moreinfo="none">rpm</application>
makes it safe to erase the old package.
<blockquote>
<para>"4. [RPM] reviews the RPM database to find every file
listed as being part of the package, and if a file does not
belong to another package, deletes the file."
<footnote>
<para>From
<xref linkend="maximumrpm" />
</para>
</footnote>
</para>
</blockquote>
</para>
</sect2>
<sect2>
<title id="twonewpackages">new packages</title>
<para>
</para>
</sect2>
<sect2>
<title id="twoetcdirectory">/etc directory</title>
<para>
</para>
</sect2>
</sect1>
<sect1 id="rpmtips" xreflabel="rpm command line tips">
<title>rpm command line tips</title>
<sect2>
<title id="twowhyreadrpm">Why do I need to read this when I'm
using a graphical frontend for rpm?</title>
<para>
</para>
</sect2>
<sect2>
<title id="twoqueryinfomation">Query the package summary
information : 'rpm -qi'</title>
<para>
</para>
</sect2>
<sect2>
<title id="twolistcontents">List the package contents : '
<prompt>$</prompt>
<command>rpm</command>
<parameter>-ql</parameter>
'</title>
<para>
</para>
</sect2>
<sect2>
<title id="twosummarizegroup">Summarize a group : 'rpm
-qg'</title>
<para>
</para>
</sect2>
<sect2>
<title id="twosummarizesystem">Summarize your system : 'rpm
-qia'</title>
<para>
</para>
</sect2>
<sect2>
<title id="twosummariesupgrades">Summarize your upgrades : 'rpm
-qip'</title>
<para>
</para>
</sect2>
</sect1>
<sect1 id="caldera3-1">
<title>Caldera 3.1 tips</title>
<sect2>
<title id="twolostpackages">Lost packages between 2.4 and
3.1</title>
<para>
</para>
</sect2>
<sect2>
<title id="tworeplacedpackages">Replaced packages between 2.4
and 3.1</title>
<para>
</para>
</sect2>
<sect2>
<title id="twofixes">Fixes</title>
<para>
</para>
</sect2>
</sect1>
<sect1 id="packageorder">
<title>Suggestions for package order</title>
<para>
</para>
</sect1>
<sect1 id="othertools"
xreflabel="Upgrade tools from the text plus others">
<title>Upgrade tools from the text plus others</title>
<sect2>
<title id="twoncftp">ncftp</title>
<para>Here are some basic commands in the ncftp command prompt,
which you will find useful when downloading the rpms.</para>
<itemizedlist>
<listitem>
<para>Set ncftp for binary transfers with binary. (This
command isn't necessary because binary is the default
transfer type.</para>
</listitem>
<listitem>
<para>There are commnands to change through the local and
remote directory (lcd, cd).</para>
</listitem>
<listitem>
<para>Listing files in the local and remote directories
(lls, ls).</para>
</listitem>
<listitem>
<para>Set a named bookmark for the server and directory
once you've found it, so that it's easy to open it the next
time.</para>
</listitem>
<listitem>
<para>get files using a wildcard.</para>
</listitem>
<listitem>
<para>See the files in your working directory and prompting
you if you'd like to [
<!-- FIXME: extra white space -->
<keycap>O</keycap>
<!-- FIXME: extra white space -->
]verwrite, [
<!-- FIXME: extra white space -->
<keycap>S</keycap>
<!-- FIXME: extra white space -->
]kip, or [
<!-- FIXME: extra white space -->
<keycap>R</keycap>
<!-- FIXME: extra white space -->
]esume the download of that file.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2>
<title id="twovariosprograms">Various programs mentioned in the
text and alternatives to them.</title>
<formalpara id="progglint" xreflabel="glint">
<title>glint</title>
<para>
<ulink
url="http://www.redhat.com/docs/manuals/linux/RHL-5.2-Manual/install-guide/manual/doc069.html">
Some instructions for Glint</ulink>
</para>
</formalpara>
<formalpara id="progdiskdruid"
xreflabel="Red Hat's Disk Druid">
<title>Disk Druid (from Red Hat)</title>
<para>
</para>
</formalpara>
<formalpara id="proglizard" xreflabel="Caldera's Lizard">
<title>Lizard (Caldera's graphical installtion tool)</title>
<para>
</para>
</formalpara>
<formalpara>
<title id="proglisa">Lisa (Caldera's console based
installation tool)</title>
<para>
</para>
</formalpara>
<formalpara>
<title id="progfips">fips</title>
<para>Homepage: ? Author: Arno Schaefer
&#60;schaefer@rbg.informatik.th-darmstadt.de&#62; Download:
ftp://sunsite.unc.edu/pub/Linux/system/Install/fips01alpha.tar.z
<ulink url="http://www.igd.fhg.de/~aschaefe/fips/">
http://www.igd.fhg.de/~aschaefe/fips/</ulink>
License: GPL and most Linux distributions carry it under the
/dostools or /dosutils directory in the primary cd.</para>
</formalpara>
<formalpara>
<title id="progkpackage">kpackage</title>
<para>
</para>
</formalpara>
<formalpara>
<title id="progls">ls</title>
<para>
</para>
</formalpara>
<formalpara>
<title id="progcp">cp</title>
<para>
</para>
</formalpara>
<formalpara>
<title id="progPHI">PHI</title>
<para>
</para>
</formalpara>
<formalpara>
<title id="progcalupgrader">Caldera Upgrader</title>
<para>
</para>
</formalpara>
<formalpara id="progtomsrlbt" xreflabel="tomsrblt">
<title>tomsrblt</title>
<para>
</para>
</formalpara>
<formalpara>
<title id="proginstallcd">Your bootable installation
CD</title>
<para>If you have a Linux installation CD that is bootable,
you should be able to get a running Linux system from it.
This system will probably have some minimal console tools
which allow you to do some maintainence on your installed
Linux, in case that is not functioning.
<orderedlist inheritnum="ignore" continuation="restarts">
<title>To gain access to this Linux on a CD:</title>
<listitem>
<para>Boot from the CD and get the installation program
started</para>
</listitem>
<listitem>
<para>Do not start re-installing!</para>
</listitem>
<listitem>
<para>Try to find another virtual console by pressing
<keycombo>
<keycap>Left-Alt</keycap>
<keycap>F1</keycap>
</keycombo>
through
<keycombo>
<keycap>Left-Alt</keycap>
<keycap>F8</keycap>
</keycombo>
<!-- FIXME: extra white space -->
. One of them should give you either a
<application>shell</application>
prompt or a
<application>login</application>
prompt.</para>
</listitem>
<listitem>
<para>If you can't find a prompt on any of those
consoles, you may have to go through some of the basic
initialization steps of the installation such as setting
up the keyboard, screen, language and mouse. But again,
do not start installing!</para>
</listitem>
<listitem>
<para>Login to the Linux system, if necessary.</para>
</listitem>
<listitem>
<para>Find a mount point that has some free space for a
new directory. (Use the
<command moreinfo="none">df</command>
command.)</para>
</listitem>
<listitem>
<para>Make a directory there to be used as a mount
point.</para>
</listitem>
<listitem>
<para>Mount a partition that you want to modify under
that mount point just created.</para>
</listitem>
</orderedlist>
</para>
</formalpara>
</sect2>
</sect1>
<sect1 id="faq">
<title>FAQ</title>
<qandaset>
<qandaentry>
<question>
<para>questions</para>
<!-- one of (CALLOUTLIST GLOSSLIST ITEMIZEDLIST ORDEREDLIST SEGMENTEDLIST SIMPLELIST VARIABLELIST CAUTION IMPORTANT NOTE TIP WARNING LITERALLAYOUT PROGRAMLISTING PROGRAMLISTINGCO SCREEN SCREENCO SCREENSHOT SYNOPSIS CMDSYNOPSIS FUNCSYNOPSIS CLASSSYNOPSIS FIELDSYNOPSIS CONSTRUCTORSYNOPSIS DESTRUCTORSYNOPSIS METHODSYNOPSIS FORMALPARA PARA SIMPARA ADDRESS BLOCKQUOTE GRAPHIC GRAPHICCO MEDIAOBJECT MEDIAOBJECTCO INFORMALEQUATION INFORMALEXAMPLE INFORMALFIGURE INFORMALTABLE EQUATION EXAMPLE FIGURE TABLE PROCEDURE ANCHOR BRIDGEHEAD REMARK HIGHLIGHTS INDEXTERM) -->
</question>
<answer>
<para>answers</para>
</answer>
</qandaentry>
</qandaset>
</sect1>
&GFDLDOC;
<bibliography>
<title>Bibliography</title>
<bibliodiv>
<title>Referenced Documents</title>
<biblioentry>
<title id="upgradehowto">"Upgrading Your linux Distribution
mini-HOWTO"</title>
<authorgroup>
<author>
<firstname>Greg</firstname>
<surname>Louis</surname>
</author>
</authorgroup>
<copyright>
<year>1996</year>
<holder>Dynamicro Consulting Limited</holder>
</copyright>
<pubdate>6 June 1996</pubdate>
<pubsnumber>v1.11</pubsnumber>
<bibliomisc>
<ulink
url="http://www.linuxdoc.org/HOWTO/mini/Upgrade.html">Refer
to an online copy</ulink>
</bibliomisc>
</biblioentry>
<biblioentry>
<title id="rpmslackwarehowto">"RPM+Slackware
Mini-Howto"</title>
<authorgroup>
<author>
<firstname>Dave</firstname>
<surname>Whitinger</surname>
</author>
</authorgroup>
<bibliomisc>
<ulink
url="http://www.linuxdoc.org/HOWTO/mini/RPM+Slackware.html">
Refer to an online copy</ulink>
</bibliomisc>
</biblioentry>
<biblioentry>
<title id="rpmhowto">"RPM HOWTO"</title>
<authorgroup>
<author>
<firstname>Donnie</firstname>
<surname>Barnes</surname>
</author>
</authorgroup>
<bibliomisc>
<ulink
url="http://www.linuxdoc.org/HOWTO/RPM-HOWTO/index.html">
Refer to an online copy</ulink>
</bibliomisc>
</biblioentry>
<biblioentry>
<title id="rpmman">rpm(8) (a man page)</title>
<authorgroup>
<author>
<firstname>Marc</firstname>
<surname>Ewing</surname>
</author>
<author>
<firstname>Jeff</firstname>
<surname>Johnson</surname>
</author>
<author>
<firstname>Erik</firstname>
<surname>Troan</surname>
</author>
</authorgroup>
<pubdate>22 December 1998</pubdate>
<publisher>
<publishername>Red Hat Software</publishername>
</publisher>
</biblioentry>
<biblioentry>
<title id="installationstratigieshowto">"Linux Installation
Strategies mini-HOWTO"</title>
<authorgroup>
<author>
<firstname>Tobby</firstname>
<surname>Banerjee</surname>
</author>
</authorgroup>
<bibliomisc>
<ulink
url="http://www.linuxdoc.org/HOWTO/mini/Install-Strategies/index.html">
Refer to an online copy</ulink>
</bibliomisc>
</biblioentry>
<biblioentry>
<title id="redhatinstallguide">"THE COMPLETE redhat LINUX
INSTALLATION GUIDE 5.2"</title>
<publisher>
<publishername>Red Hat Software, Inc.</publishername>
</publisher>
<corpauthor>Red Hat Software, Inc.</corpauthor>
<pagenums>24-25</pagenums>
<copyright>
<year>1995, 1996, 1997, 1998</year>
<holder>Red Hat Software, Inc.</holder>
</copyright>
<isbn>1-57595-199-1B</isbn>
<corpname>
<trademark>Red Hat</trademark>
is a trademark of Red Hat Software, Inc. Copy
Writer</corpname>
<bibliomisc>
<ulink
url="http://www.redhat.com/docs/manuals/linux/RHL-5.2-Manual/install-guide/manual/">
Download a copy from the Red Hat</ulink>
</bibliomisc>
</biblioentry>
<biblioentry>
<title id="partitionhowto">Linux Partition HOWTO</title>
<authorgroup>
<author>
<firstname>Tony</firstname>
<surname>Harris</surname>
</author>
<author>
<firstname>Kristian</firstname>
<surname>Koehntopp</surname>
</author>
</authorgroup>
<pubsnumber>Revision 3.3</pubsnumber>
<pubdate>10 July 2001</pubdate>
<bibliomisc>
<ulink
url="http://www.linuxdoc.org/HOWTO/mini/Partition/index.html">
Refer to an online copy</ulink>
</bibliomisc>
</biblioentry>
<biblioentry>
<title id="ncftpman">ncftp(1) Man page</title>
<pubsnumber>3.0.2</pubsnumber>
</biblioentry>
<biblioentry>
<title id="maximumrpm" xreflabel="Maximum RPM">Maximum
RPM</title>
<edition>FIRST</edition>
<copyright>
<year>1997</year>
<holder>Red Hat Software, Inc.</holder>
</copyright>
<isbn>0-672-31105-4</isbn>
<corpname>
<trademark>RPM is a trademark of Red Hat Software,
Inc.</trademark>
</corpname>
<authorgroup>
<author>
<firstname>Edward</firstname>
<othername>C.</othername>
<surname>Bailey</surname>
</author>
</authorgroup>
</biblioentry>
</bibliodiv>
<bibliodiv>
<title>Related HOWTOs</title>
<biblioentry>
<title id="installationhowto">The Linux Installation
HOWTO</title>
<copyright>
<year>2000</year>
<holder>Eric S. Raymond</holder>
</copyright>
<authorgroup>
<author>
<firstname>Eric</firstname>
<othername>Steven</othername>
<surname>Raymond</surname>
<affiliation>
<orgname>Thyrsus Enterprises</orgname>
</affiliation>
</author>
</authorgroup>
<pubsnumber>Revision 5.6</pubsnumber>
<pubdate>2001-09-06</pubdate>
<bibliomisc>
<ulink
url="http://www.linuxdoc.org/HOWTO/Installation-HOWTO/index.html">
Refer to an online copy</ulink>
</bibliomisc>
</biblioentry>
<biblioentry>
<title id="swapspacehowto">Linux Swap Space
Mini-HOWTO</title>
<authorgroup>
<author>
<firstname>Rahul</firstname>
<othername>U.</othername>
<surname>Joshi</surname>
</author>
</authorgroup>
<pubsnumber>v1.42</pubsnumber>
<pubdate>18 January 2000</pubdate>
<bibliomisc>
<ulink
url="http://www.linuxdoc.org/HOWTO/mini/Swap-Space.html">
Refer to an online copy</ulink>
</bibliomisc>
</biblioentry>
<biblioentry>
<title id="filesystemshowto">Filesystems-HOWTO.html</title>
<authorgroup>
<author>
<firstname>Martin</firstname>
<surname>Hinner</surname>
</author>
</authorgroup>
<pubsnumber>Version 0.7.5</pubsnumber>
<pubdate>22 August 2000</pubdate>
<bibliomisc>
<ulink
url="http://www.linuxdoc.org/HOWTO/Filesystems-HOWTO.html">
Refer to an online copy</ulink>
</bibliomisc>
</biblioentry>
</bibliodiv>
</bibliography>
</article>
<!--
$Id$
-->