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
1.4G hda1 FAT /c
0.5G hda2 ext2 /, /usr, /etc, /home
0.1G hda3 linux swap
2.0G hda4 ext2 /var, /opt, /tmp
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
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.
This is egregiously dangerous behavior for an "upgrade"
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 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!
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.
Carlie J. Coats, Jr. email@example.com
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.
"My opinions are my own, and I've got *lots* of them!"
Yes, this is a problem deep in the depths of RPM and the installer.
Computing the amount of disk space needed for upgrades is not trivial
at all. It is quite complex and hard to get right. We are working on
fixing this as soon as we can, but it may take some fairly heavy
reworking of lots of code.
Fixed in 6.0