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.
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. 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.
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 intelligently. *** This bug has been marked as a duplicate of 73318 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.