Trying to upgrade from 6.0 to 6.1
I have a cable modem with 20ms ping to ftp server.
I had a 20 minute wait during the "Finding packages to upgrade", and then
a 20 minute wait between each package that downloaded, I waited until I
was three packages in and then canceled (1 hour out of something like 2783
hours it was estimating it was going to take). As soon as the ftp session
actually was reset and the file transfered, the package installed. But
then the next package went back into long wait mode.
I am using the updated bootnet.img and updates disks.
To get around this problem, I am attempting to ftp all the files down to
my PC first (downloading extremely fast - < 30 minutes to download the
entire distribution) and then install via http. Meanwhile this annoying
bug really needs to get fixed to allow people who do not know enough about
Linux to get it on their systems!!! If people can't install Linux without
so many problems, its going to be harder to get marketshare...
I had the same experience: a 20-minute (or more) delay during the "finding
packages to upgrade" screen, then a 20-minute (almost exactly) delay between
each successive package being downloaded and installed. I am trying to upgrade
from RH 5.2 to 6.1, on an IBM ThinkPad 560Z using a 3Com/MegaHertz 10/100
Cardbus Ethernet card (3CXFE575BT). The FTP server is on the campus network and
responds quickly to all other requests. Very frustrating!
I've had the same experience with FTP installtion of rh 6.1.
I'm using the new updated bootnet.img disk on a P133 with a netgear(tulip)
network card. I've got a cable modem connection and I'm installing from
ftp.sunet.se/pub/Linux/distributions/redhat/redhat-6.1/i386, probably the
fastest ftp server I've got access to.
After 6 hours I had installed 27 packages and had a estimated time of 100 hours+
and 500 packages+ left of the installation (according to the installation
I see that it has almost been a month since this bug was first reported. Has
anybody taken any action to fix this yet? It's frustrating!
This might already be known to you but when I searched for it in Bugzilla I
couldn't find it.
This problem seems to only appear for me when I chose the "Install KDE
Workstation" together with FTP or HTTP install. To make it work I picked the
"Custom Installation" option together with HTTP installation. I never checked if
it works in the same way with FTP but I'd guess it does.
It seems to me that the current Install Workstation options should be avoided.
I have the same problem with long waits (in fact, the only reason I realized
it's a wait and not a complete freeze was that I got hungry in the process and
went to grab a bite). It doesn't seem to matter which install option I choose.
The network card is a built-in Intel EtherExpressPro 10/100 (eepro100.o)
And (among other things) the driver says:
eth0: OEM i82557/i82558 10/100 Ethernet
Receiver lock-up bug exists -- enabling work-around
Well, that --apparently-- didn't solve the problem (if it has anything
to do with it, anyway).
BTW, bug #8588 looks very much the same...
The latest installer available in RawHide does not perform multiple sessions for
file retrieval, instead just opening one session with the FTP server and then
pulling the stuff through the session. This should solve this wait problem, as
the installer is no longer trying to extablish one session for every package
which is brought down.