Bug 72263 - cannot install from NFS .iso or loopback mounted .iso
cannot install from NFS .iso or loopback mounted .iso
Status: CLOSED DUPLICATE of bug 73318
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-22 11:40 EDT by John Reiser
Modified: 2008-01-17 12:49 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:49:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Reiser 2002-08-22 11:40:35 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529

Description of problem:
I could not install using an NFS-exported directory containing the first 3 .iso
images.  Also, I could not install using an NFS-exported directory containing
three sub-directories disc1, disc2, disc3 which were loopback mounts of each
corresponding .iso image.  What did work was an NFS-exported subdirectory
containing copies of the RedHat directory from all the discs.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Put first three .iso images into a directory, and NFS-export the directory
from RHL 7.3/i686 system updated to 2002-07-01.
2. bootnet, linux askmethod, NFS, configure TCP, configure NFS.  Installer
complains that it cannot find RedHat installation.

3. [another attempt] Loopback mount each .iso on a corresponding disc1, disc2,
disc3 directory, and NFS configure the installer to the directory containing the
disc1, disc2, disc3 mount points.  Installer still complains cannot find RedHat
installation files.

	

Actual Results:  Installer fails with NFS-exported directory containing only
.iso files.

Installer fails with NFS-exported directory containing loopback mounts of .iso
files.

Installer succeeds with NFS-exported subdirectory containing copies of collected
RedHat subdirectories.

Expected Results:  Installer should have succeeded with NFS-exported directory
containing .iso images.  This is documented in
http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/install-guide/s1-x86-begininstall-net.html
-----
Using ISO Images for NFS Installs

NFS installations can use ISO (or CD-ROM) images rather than copying an entire
installation tree. After placing the required ISO images (the binary Red Hat
Linux CD-ROMs) in a directory, choose to install via NFS. You will then point
the installation program at that directory to perform the installation. 
-----

Installer should have succeeded with NFS-exported directory containing
subdirectories disc1, disc2, disc3 with loopback mount of corresponding .iso
file.  This is documented in
http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/install-guide/s1-x86-begininstall-ftp.html
-----
Tip 

You can also install Red Hat Linux using ISO images without copying them into a
single tree by loopback mounting them as:

disc1/,disc2/,disc3/
-----
[This Tip deserves a better explanation, with an example of exactly how to
perform the mount(s).  And if the Tip applies only to FTP and not to NFS or
HTTP, then that should be mentioned.]

Additional info:

Some parts of this bug probably are related to bug 58289.
Comment 1 Michael Fulbright 2002-08-22 12:21:04 EDT
I do this daily as part of a automated test we run - what kind of server are you
serving the ISOs from?
Comment 2 John Reiser 2002-08-22 13:03:41 EDT
The .iso images are in a directory that is exported by a RHL 7.3/i686 system
updated to 2002-07-01 (Steps to Reproduce, Step 1.)

On the exporting system, service portmap is started at boot, service nfs is not
started at boot but started just before doing the install, /etc/exports is
[would be] valid at boot and is not changed.  Ipchains blocks NFS at boot, but
service ipchains is stopped just before doing install [DSL hardware router box
has firewall, too.]  At the time of installation, a third box on the same
network can NFS mount the exported directory [by hand with no options, not by
/etc/fstab] and see the .iso files, but cannot see into the directories which
have the loopback mounts [bug 58289.]
Comment 3 Jeremy Katz 2002-08-22 17:31:00 EDT
The loopback mounts won't work, but the isos just sitting there should.  Are you
able to mount them via loopback from another machine over NFS?
Comment 4 John Reiser 2002-08-22 18:35:46 EDT
Egg on my face:  Attempting to loopback mount a .iso file (served by NFS) on a
third box gets "Permission denied" because the permissions on the .iso file are
0600 (-rw------) set by security/privacy-conscious Mozilla.  Changing to 0644
(-rw-r--r--) enables the loopback mount on the third box to succeed.

So: the installer should give the actual error "Permission denied", which gives
a strong hint about what is wrong and how to fix it, instead of just a catch-all
message like "cannot find RedHat installation".
Comment 5 Jeremy Katz 2002-08-23 03:38:02 EDT
Except that it's not really the case -- we don't know that random files just
aren't ISOs and without the ability to mount them, we can't do any investigation.
Comment 6 John Reiser 2002-08-23 12:45:35 EDT
Please turn this into a Request for Enhancement regarding error reporting.  This
is a significant Usability and Reliability/Robustness issue, and more thorough
error reporting would help a lot, both at the time of installation and in
long-term user satisfaction.

suggested Summary:
RFE: log of file accesses by installer

suggested Description of Problem:
General error messages like "cannot find RedHat installation files" frustrate
the user because they do not provide good clues about the specific problems and
what might be done to fix/workaround them.  In the particular case of NFS
install, having "no read by Other" access permission on the remotely-served .iso
image files currently gives only a catchall message instead of something helpful
which might include, for example, "EPERM (Permission denied):
null-i386-disc1.iso" when the file has permissions 0600 on the exporting machine.

suggested Implementation:
Have each install method keep a text log file of each attempted file access and
its status [including success, such as "Disc1 found"], and mention the name of
the log file in error reports to the user.  The user should be able to access
the log during install via alternate screens, for instance by <Alt>-F2 and "cat
name_of_log_file".

alternate Implementation:
Provide an install mode which runs the installer under strace, recording tje
open/access/stat syscalls, or even all syscalls.
Comment 7 Jeremy Katz 2002-08-23 15:09:18 EDT
How exactly are you proposing that you even get a shell on tty2?  We don't have
space on the floppies for a shell and so the shell isn't available until after
the second stage has been loaded.  And if we log too much information to a tty,
then it's impossible to find the real messages which do have to be there for
when we're debugging problems from the loader.  There is another bug about
making nfsiso a little bit smarter in this case, but I can't find it at the moment.
Comment 8 Michael Fulbright 2003-03-12 12:37:34 EST
This is a dupe of a similar bug basically saying we need to handle NFS isos more
intelligently.

*** This bug has been marked as a duplicate of 73318 ***
Comment 9 Red Hat Bugzilla 2006-02-21 13:49:28 EST
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.