Red Hat Bugzilla – Bug 72263
cannot install from NFS .iso or loopback mounted .iso
Last modified: 2008-01-17 12:49:41 EST
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):
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
Actual Results: Installer fails with NFS-exported directory containing only
Installer fails with NFS-exported directory containing loopback mounts of .iso
Installer succeeds with NFS-exported subdirectory containing copies of collected
Expected Results: Installer should have succeeded with NFS-exported directory
containing .iso images. This is documented in
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
You can also install Red Hat Linux using ISO images without copying them into a
single tree by loopback mounting them as:
[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.]
Some parts of this bug probably are related to bug 58289.
I do this daily as part of a automated test we run - what kind of server are you
serving the ISOs from?
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.]
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?
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".
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.
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.
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.
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
Provide an install mode which runs the installer under strace, recording tje
open/access/stat syscalls, or even all syscalls.
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.
This is a dupe of a similar bug basically saying we need to handle NFS isos more
*** This bug has been marked as a duplicate of 73318 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.