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"
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Perform an FTP install
Actual Results: Installation fails during "hdlist2" FTP transfer with
an "out of space" message.
Expected Results: Should have transferred.
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
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
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
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
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.