Bug 86356 - FTP install fails with non-anonymous account
Summary: FTP install fails with non-anonymous account
Status: CLOSED DUPLICATE of bug 84692
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2003-03-20 10:48 UTC by Need Real Name
Modified: 2008-01-17 17:49 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-02-21 18:52:15 UTC

Attachments (Terms of Use)

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:

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.

Note You need to log in before you can comment on or make changes to this bug.