Bug 236
| Summary: | Install "upgrade" badly corrupted my system | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | coats |
| Component: | installer | Assignee: | Matt Wilson <msw> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.2 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 1999-04-26 23:34:59 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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 |
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!"