Bug 56935

Summary:	Improve error handling on installs and to save options selected
Product:	[Retired] Red Hat Linux	Reporter:	Matthew Sell <msell>
Component:	anaconda	Assignee:	Matt Wilson <msw>
Status:	CLOSED WONTFIX	QA Contact:	Brock Organ <borgan>
Severity:	high	Docs Contact:
Priority:	medium
Version:	7.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:	2003-03-04 21:40:08 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:

Description Matthew Sell 2001-11-30 17:35:01 UTC

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

Description of problem:
I am upgrading a 7.1 box to 7.2, and the FTP install failed the first 
time. The partitions were upgraded to EXT3. On the second attempt, the 
EXT3 partitions are mounted with GROSS errors in reported sizes. For 
example, a 53 Meg partition is now 53K. A 15G partition is reported as 
15M. The install process fails during FTP transfer with "out of space" 
messages.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Perform an FTP install
2.
3.
	

Actual Results:  Installation fails during "hdlist2" FTP transfer with 
an "out of space" message.

Expected Results:  Should have transferred.

Additional info:

I saw this on a machine of mine at home - same EXACT problem, but using a 
dual Pentium 2 on an Intel MB instead of a dual Athlon with Tyan MB at 
work. Both had multiple IDE partitions (I segregate VAR onto a separate 
partition, usually around 50 MB), and Raid Level 1 on at least one 
partition. I verified the mismatch by running FDISK, and the discrepancy 
is plainly obvious. The sizes are off by an order of 1000.

Comment 1 Matthew Sell 2001-11-30 21:16:39 UTC

Looks like this problem has two parts - both of which are problems, but one is 
minor (very minor), and the other is not as bad, and has a workaround.

The first problem is that the version of "df" reports sizes divided by 1000 
when using "df -h". When using "df" with no options, the sizes are reported 
correctly. When viewing partition sizes and free space using "df -h", the 
values returned lead you to a false conclusion regarding the partitioning. 
Use "df" with no options and you will get an accurate report.

The second problem is that when running the FTP install, and you have a network 
timeout, or the computer locks up, the installation routine does not remove 
temporary files. If you have a partition for /var, and there is not a lot of 
space available (I had 40 meg available), and you have multiple restarts, then 
the installation routine will not be able to store packages for install.

The workaround is to use the console (ctrl-F2) and remove temporary files from 
the /var directory that were left behind by previously aborted installation 
attempts.

The installation routine (anaconda?) needs to remove any temporary files before 
installation. By doing this, problems with multiple restarts do not fail later. 
The installation routine needs to have the ability to retry an FTP install if a 
package fails to download. Even on a LAN, when doing FTP installs, sometimes a 
network glitch or cable problem may prevent a package from downloading, and the 
installation hangs. An option to attempt a reconnect to download that package 
and continue would be nice. Especially if the install fails on one of the last 
ten packages after installing about 900 meg worth of stuff previously. Kinda 
frustrating to start over....

Comment 2 Michael Fulbright 2001-12-03 20:47:40 UTC

Thank you for your input on this bug - does it help the original poster?

Comment 3 Brent Fox 2002-01-21 04:49:26 UTC

Uh, both reports are from the same person.  How feasible is it for anaconda to
remove the temporary files if the network connection has problems?  At what
point could anaconda decide that the network connection had died and then start
cleaning up the temp files?  I don't see how you could do it in a safe way...

Comment 4 Matthew Sell 2002-01-21 14:14:25 UTC

I think the solution is pretty clear:

1) When the installation process starts, Anaconda 
needs to remove any temporary files that may have been "orphaned" during a previously aborted 
installation.

2) During package download, Anaconda needs to enforce a "timeout". If the 
package download is unsuccessful, the user needs to be presented with the following 
options:

   a) Retry (user may have fixed problem)
   b) Retry using a different FTP site (if 
successful - continue to use the new site)
   c) Abort. Save the state of Ananaconda - including 
packages selected

3) Ananconda needs to save it's state during each stage of the install 
process. This way, if a package download or any other error foces a restart, then the user could be 
prompted to continue from where they left off. Having to restart and then reselect the packages 
again is a real pain and time killer.

4) There needs to be a way to save the options selected 
to floppy. This way, a user can take the options selected in the menuing system and apply them 
to a new install of another box. Maybe Ananconda could have a menu option for loading 
configuration from disk for selections that are appropriate (package selections, etc.)

Comment 5 Jeremy Katz 2002-04-08 23:19:42 UTC

Deferring to a future release

Comment 6 Michael Fulbright 2003-03-04 21:40:08 UTC

The out of space issue is duplicated in other bugs reports, and we do not have
plans to save the installation options chosen to disk other than in the form of
the anaconda-ks.cfg file.