|Summary:||FTP install fails with non-anonymous account|
|Product:||[Retired] Red Hat Linux||Reporter:||Need Real Name <graeme.hewson>|
|Component:||anaconda||Assignee:||Jeremy Katz <katzj>|
|Status:||CLOSED DUPLICATE||QA Contact:||Mike McLean <mikem>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-02-21 18:52:15 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Need Real Name 2003-03-20 10:48:53 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 Description of problem: Unable to read package information due to using relative path. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: Booting from diskette, using text mode. ISO images loop mounted on FTP server as /disc1, /disc2, /disc3. Using non-anonymous FTP account. When retrieving the installation image, the installer uses a full path. Specifying path "/" to the installer, it issues the FTP command: RETR /./disc1/RedHat/base ... and this succeeds. However, when the installer comes to read the package information, it uses a relative path and issues the FTP command: CWD disc1 which is relative to the home directory of the FTP account, and this fails. The process also fails if the ISO images are mounted as sub-directories of the FTP account home directory, say as /home/user/iso/disc1, etc. If "iso" is specified to the installer, it assumes this is an absolute path (and "/iso" with the leading slash appears in the dialog box). If "/home/user/iso" is specified, the boot succeeds, but reading the package information fails since the installer issues the FTP command "CWD home". Clearly the installer is assuming a chrooted environment. Workaround is to set up symbolic links to satisfy both the boot process and the unpackaging process. This seems to be the problem reported in bug 76217 (looking at "Actual Results"), but I thought it best to open a new bug. Additional info:
Comment 1 Michael Fulbright 2003-03-20 16:44:28 UTC
I'm fairly certain Jeremy got a fix in for this.
Comment 2 Jeremy Katz 2003-03-24 17:30:31 UTC
*** This bug has been marked as a duplicate of 84692 ***
Comment 3 Red Hat Bugzilla 2006-02-21 18:52:15 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.