On 11/10/2011 02:36 AM, Jean-Michel Barbet wrote:
Hello all,

One of our colleagues is performing network installs of SL.
He frequently observes that the install fails on downloading always the
same package (depending on the SL version and arch) with a message
saying that the package is not found or damaged.

He has tried different mirrors with the same result. Removing the
package from the list of packages to install result in the install
process failing on another package. The protocol is FTP.

=> Anybody has similar experiences ? Solutions ?

Thank you.

JM


I can say from our side that, excluding the announced outages, we've been up.

$ ssh ftp.scientificlinux.org
$ uptime
 08:43:33 up 25 days, 18:40,  1 user,  load average: 0.49, 0.33, 0.29
$^D
$ ssh ftp1.scientificlinux.org
$ uptime
 08:44:25 up 25 days, 16:32,  1 user,  load average: 0.22, 0.17, 0.19
$^D
$ ssh ftp2.scientificlinux.org
$ uptime
 08:45:17 up 25 days, 16:33,  1 user,  load average: 0.00, 0.01, 0.00
$^D
$ ssh rsync.scientificlinux.org
$ uptime
 08:45:42 up 25 days, 18:42,  1 user,  load average: 1.21, 1.09, 0.82
$^D

As an aside, our experience internally has been that FTP is a bit more chatty than HTTP for installs. It seems that Anaconda sometimes likes to traverse each piece of the install path (ie open ftp.scientificlinux.org ; cd /linux ; cd scientific ; cd 6x ; cd i386 ; cd os ; cd Packages ; get foo.rpm; close ; open ftp.scientificlinux.org ; cd /linux ..... and so on). If you have some sort of caching proxy, perhaps it doesn't like this behavior. Is HTTP an option for your installs? Do you have the space for a local, private, mirror?[1] As of 5 minutes ago SL6x is just shy of 41G (a hefty download to say the least), but that includes all archive, source, and iso files.

Pat

[1] http://www.scientificlinux.org/download/mirroring/

--
Pat Riehecky
Scientific Linux Developer

Reply via email to