|Summary:||Installer dies with python exception on ftp install from ftp.redhat.com|
|Product:||[Retired] Red Hat Linux||Reporter:||msnellenberg|
|Component:||installer||Assignee:||Jay Turner <jturner>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||1999-11-02 18:41:22 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description msnellenberg 1999-11-02 07:08:02 UTC
Trying to do an ftp install from ftp.redhat.com. IP config works, ftp settings work and second stage ramdisk is retrieved, but then installer dies with a python exception (no way of saving this, and too damn long to write out longhand!) as it's going into the package selection stage. The important bits are that it can't find a file at: ftp://ftp.redhat.com/redhat/redhat- 6.1/i386/RedHat/base/hdlist Has happened 5 or 6 times in a row. I am able to get further in an install from a mirror site (ie I select packages and they start downloading), but usually (with my luck) the ftp connection dies somewhere while moving the 300 megs.. A smarter recovery mechanism sure would be nice... <:)
Comment 1 Jay Turner 1999-11-02 15:56:59 UTC
One problem that we have seen with FTP installations is that you must provide a fully-qualified doamin name for the FTP server and you must *NOT* put a trailing slash at the end of the path to the source files. So, if I am installing from porkchop.redhat.com and the files are in /mnt/redhat/test/6.1/i386, then I would want to enter "porkchop.redhat.com" as the server and "/mnt/redhat/test/6.1/i386" as the pathname . . . not "/mnt/redhat/test/6.1/i386/" Reopen this bug if this does not fix your problem.
Comment 2 msnellenberg 1999-11-02 17:57:59 UTC
I saw this on some previous bugs, and did indeed try it without the trailing slash.
Comment 3 Jay Turner 1999-11-02 18:41:59 UTC
OK, I am going out on a limb here, but I think that I know what you are seeing. The ftp.redhat.com ftp server is extremely busy, and the chances that you are able to get a connection twice in a row (to retrieve the second stage image and then again, later, to retrieve the packages) is slim to none, so I am thinking that the installer is not handling the denial of connection very well. We already have a number of bugs about not handling loss of and denial of connection very well, so unless I hear otherwise, I am going to merge this bug with those. You might want to try an ftp install from one of the mirrors that is closer to you and has a pretty reliable connection, or try a different install method.