Hide Forgot
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.
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....
Thank you for your input on this bug - does it help the original poster?
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...
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.)
Deferring to a future release
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.