by 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).
Be **very** careful about using RedHat 5.2 installation's "upgrade
option!! On the basis of my experience it 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.
Ha!
"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.
IMNHO
<RANT>
This is egregiously dangerous behavior for an "upgrade" program.
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.
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.
It is at worst a two-banana problem to program a simulation of
the upgrade process and see if it will fits in the available space.
And if it won't, offer an option to back out of the process,
damn it!
And make the *Hell* sure you have the resources to upgrade LILO
before you corrupt it! And *don't* corrupt the partition tables,
damn it !!
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.
</RANT>
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!"