Description of problem: Can not install RHEL4 U8(x86_64) due to failing to NFS mount for access to the install source. Version-Release number of selected component (if applicable): RHEL4-U8-re20090325.0 How reproducible: This is the machine-dependent probrem. - nec-em11 always occur. - nec-em19 doesn't occur. Steps to Reproduce: Try to install RHEL4-U8-re20090325.0(x86_64) or the higher on nec-em11. Actual results: Sending request for IP information for eth1... Determining host name and domain... mount: RPC: Timed out +-----------+ Error +------------+ | | | That directory could not be | | mounted from the server. | | | | +----+ | | | OK | | | +----+ | | | | | +--------------------------------+ Expected results: Should be able to install Additional info: - Can install RHEL4 U8(x86_64) on nec-em11 if we retry the mount after the error occurs. - Can install RHEL4 U8(i386) on nec-em11. - Can install RHEL4 U7(x86_64) on nec-em11. Please feel free to ask me if you need additional information.
(In reply to comment #0) > This is the machine-dependent probrem. > - nec-em11 always occur. > - nec-em19 doesn't occur. Please provide links to failed automated jobs or some logs from the install. This could be failure with the NFS server, machine dependent problem or a real bug in anaconda. Have you tried the failing machine with http ? How does the machine boot cd, pxe, kernel+initrd.img pair? Do you use exploded NFS tree or NFS ISOs ?
Created attachment 337960 [details] this ks.cfg is when the failure occured. We have additional information related to the install failure. The failure occurs in one of the following conditions. - Using NFS access to ks.cfg in boot options (e.g. ks=nfs:"server":"path") - Using NFS access to a install source in ks.cfg (e.g. nfs --server="server" --dir="path") So, we can install RHEL4(x86_64) in the following combinations. - ks=hd:"device":/ks.cfg and using http access to the install source - ks=http://"server"/"path" and using http access to the install source > Please provide links to failed automated jobs or some logs from the install. > This could be failure with the NFS server, machine dependent problem or a real > bug in anaconda. I ran a job via RHTS. The following link is related to the failed job. But we can only get the console log in the link. So, in addition to the link I attach ks.cfg which is when the failure occurred. http://rhts.redhat.com/cgi-bin/rhts/jobs.cgi?id=53070 > Have you tried the failing machine with http ? The installation is successful when we use http access to the install source. > How does the machine boot cd, pxe, kernel+initrd.img pair? I tried to boot the machine by using both kernel+initrd.img pair(kickstart) and pxe(RHTS). > Do you use exploded NFS tree or NFS ISOs ? I use exploded NFS tree on bigpapi.bos.redhat.com.
Keiichi-san, This sounds like a duplicate of bug 492331. Can you try the failing machine with -0401.0 build?
Currently, I have gotten needinfo request. But I don't know Anaconda Maintenance Team needs any information. If the information in Comment #3 is insufficient, please tell me the needed information.
Comment #4 was the one asking for more information, and was basically if you can try with the 0401.0 tree.
Making comment #4 public.
I tried to install RHEL4-U8-re20090401.0 in the failing machine. But I couldn't install the RHEL4 due to the same NFS mount failure. The following link is related to the failed task. http://rhts.redhat.com/cgi-bin/rhts/jobs.cgi?id=57268 I think there is no relation between BZ492331 and BZ493210. Because the cause of the failure in BZ493210 is the NFS mount failure after loading the kernel/initrd images.
There's no RHEL4-U8-re20090401.0 build in RHTS. The cited job dates back to May and it's possible that this build has been deleted from disk to save space but was present in the distros database. The only RHEL4-U8 build in the database now is RHEL4.8 GA. If you can reproduce with 4.8 GA or one of the latest nightly builds for 4.9 please re-open this issue.