I have just spent much of the last two days trying to
repair the situation left by the "upgrade option in RedHat
5.2's installation program (still have quite a bit of work
rebuilding additional software to do to get back to my
previous state--I'm downloading via T3 at the office, then
will sneakernet the stuff home via Zip disks this evening).

On the basis of my experience RedHat 5.2 installation's
"upgrade option should be considered extremely dangerous.

I have a Micron PPro system, 128M ram, 4G Western Digital
and 8G Maxtor IDE hard drives, IDE Zip, IDE CD, dual boot
(RH linux 4.1 and Win95 (which I hadn't booted since before
last Thanksgiving)).  The system was partitioned as
follows:

    4G hda:
        1.4G hda1 FAT   /c
        0.5G hda2 ext2  /, /usr, /etc, /home
        0.1G hda3 linux swap
        2.0G hda4 ext2  /var, /opt, /tmp

    8G hdb
        2.0G hdb1  FAT   /d
        5.9G hdb2  ext2  /work
        0.1G hdb3  linux swap

hda2 was 90% full (all of this stuff is fairly stable, and
I followed "conventional wisdom" by making this partition
conform to the actual size of its contents.)  Other ext2
partitions were 50% or less (which means in particular that
you have at least 1G to play with in /tmp). "3rd-party"
software is in /opt/local, on hda4.

The RH 5.2 instruction book does not suggest any other
means than their "upgrade" program for installing this
release.  I figure I'll set up a relatively small custom
upgrade, selecting a package configuration which fits
comfortably within the 0.5G of my hda2 partition, and don't
really expect any problems.

"upgrade" runs off a booting floppy, and assumes you have
the distribution CD in your CD-drive.  As you select a
"custom" upgrade, it continuously gives you a size report
on the upgrade configuration you are selecting.  I tailored
a configuration which allegedly occupied 420 M, which
_should_ be safe, I thought.

Once it started, "upgrade" gives a running tally of what
it has installed.  In many cases, it popped up a window
indicating failure because it had run out of space trying
to decompress the indicated package.  In the process, it
also corrupted the partition tables on both disks,
corrupted LILO, and claimed it could not make a rescue
boot floppy.

Attempting a simple "install" into the existing partitions
didn't work, either.  I am now in the process of
re-building the whole system  from scratch.

<RANT>
IMNHO
<UL>
    <LI>
    This is egregiously dangerous behavior for an "upgrade"
    program.

    <LI>
    For an upgrade, you *already have* a working Linux
    system.  You can find out exactly what its resources
    are in advance.  You can use its /tmp as scratch space
    if you want.

    <LI>
    You damned well *ought* to know not only how much space
    the resulting packages will take, but also how much
    scratch disk space it will take to decompress them.

    <LI>
    It is at worst a two-banana problem to programa
    simulation of the upgrade process and see if it will
    fits in the available space.  It's a 3-banana problem
    to program a "greedy" algorithm to do this in a near
    optimal way. And if it won't fit, offer an option to
    back out of the process, damn it!

    <LI>
    And make the *Hell* sure you have the resources to
    upgrade LILO before you corrupt it!

    <LI>
    And *don't* corrupt the partition tables, damn it !!

    <LI>
    Instead of insisting that "upgrade" act as a standalone
    boot process booted from its own floppy, why not make
    provision for upgrade from "root" acting at an
    appropriate run-level?  That way, you'd be able to
    control the whole thing better (and the result could
    still be much less tedious than a one-at-a-time
    manually-controlled upgrade using RPM.
</UL>
</RANT>

Carlie J. Coats, Jr.                         coats
MCNC Environmental Programs            phone: (919)248-9241
North Carolina Supercomputing Center     fax: (919)248-9245
3021 Cornwallis Road                        P. O. Box 12889
Research Triangle Park, N. C.
27709-2889                         USA
"My opinions are my own, and I've got *lots* of them!"