Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 6096 - network installer is broken
Summary: network installer is broken
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: installer
Version: 6.1
Hardware: i386
OS: Linux
high
high
Target Milestone: ---
Assignee: Matt Wilson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-10-19 20:07 UTC by lars
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-10-22 19:39:52 UTC


Attachments (Terms of Use)

Description lars 1999-10-19 20:07:41 UTC
Performing a network install from the 6.1 bootnet.img.  As
the install was about to begin (i.e., just after choosing
which partititions to format), I received a python traceback
which appears to have been caused by an unexpected response
from the ftp server:

  Traceback (innermost last):
    File "/usr/bin/anaconda.real", line 255, in ?
  .
  .
  .
  File
  "/var/tmp/python-root/usr/lib/python1.5/ftplib.py", line
201, in getresp
  IOError: [Errno ftp error] 500 'CWD ': command not
understood

There may be two problems here; I am not familiar enough
with the ftp protocol to know whether 'CWD ' is the same as
'CWD' (i.e., does the trailing space make a difference?).

In any case, the more serious bug is the installer's
response to this problem.  A well-written, user-friendly
installer should either:

  (a) retry the command, and/or
  (b) prompt the user for a different ftp site

Crashing out of the installer isn't going to inspire
confidence in the casual user.

Comment 1 lars 1999-10-19 20:22:59 UTC
Further testing reveals that the network installer is simply broken;
the same error occurs with any ftp site.  That is, it appears to be
imposssible to complete a network install of RH6.1.

Comment 2 Jay Turner 1999-10-20 15:14:59 UTC
We are aware of a couple of problems with FTP installs, and these
might be what you are seeing.  We are able to perform FTP (as well as
the other network protocols) installations here in the lab and have
reports of people performing them in the real world, so this is
definitely a problem which can be fixed.

There are only 2 ways to successfully install via FTP:
1) give the fully qualified domain name of the FTP server, and do not
put a trailing slash on the path to the source files (so, if you are
installing from "porkchop.redhat.com" and the source files are in
"/mnt/test/cartman/i386", these are exactly what you would type . . .
be sure you are not giving the path as "/mnt/test/cartman/i386/" as
this will cause a python excpetion.

2) give the IP address of the server, and do not include a trailing
space on the path to the source files . . . just as above.

I am forwarded this bug to a developer for action in the next
release.  Please followup if this does not solve your problems and we
will look for another solution.

Comment 3 adrian.lawrence 1999-10-20 19:42:59 UTC
I see the same bug and the comment about specifying the domain names
and paths do *not* resolve the problem. The ftp server was
wu-ftpd-2.5.0-5.6.0 running under Redhat 6.0.

Furthermore, attempting to use nfs instead results in problems at much
the same place:-

"Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix[:exec_prefix>]
Traceback (innermost last):
 File "/usr/bin/anaconda", line 13, in ?
 import gettext
 ImportError: No module named gettext
install exited abnormallly, blah,blah.....

This problem seems to arise in several related bugzilla #'s. The
comments there about case sensitivity in FAT/msdos file systems do not
apply to my case.

Comment 4 adrian.lawrence 1999-10-20 22:09:59 UTC
My problem has been resolved: an inadequately deep mirror! wget -r was
used to collect files. There is a default recursive depth of 5, and I
forgot to set this to a larger value with -l. As a result, some deeper
parts of the instimage were omitted. The symptoms that I experienced
have been widely reported on various mailing lists. Maybe this is a
common problem


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