Bugzilla – Bug 335289
AutoYaST fails to fetch config file via NFS
Last modified: 2007-11-20 15:07:44 UTC
I am network installing openSUSE 10.3 on a 32-bit i386-type PC (first generation AMD Athlon processor), with much of the configuration process controlled by AutoYaST. I am booting the workstation using a CD-R created using the openSUSE-10.3-GM-i386-mini.iso image. The repository that I am using for the installation is accessible via HTTP (boot option install=http://mirror.ox.ac.uk/sites/ftp.opensuse.org/pub/opensuse/distribution/10.3/repo/oss/) but the AutoYaST control file is fetched by NFS from a server on the local LAN (boot option autoyast=nfs://willis.physiol.ox.ac.uk/export/suse/autoyast/). The autoyast directory on the NFS server contains a single XML control file named "default". The NFS server is a SunBlade 1000 UltraSPARC workstation, running Solaris 9. This configuration worked for me without any problem when installing openSUSE 10.2. The kernel boots from CD-R and fetches the installation ramdisk image from the HTTP server without incident. The "System Probing" checklist goes without incident, but when the installer tries to fetch the autoyast profile from the NFS server, it fails. I get a dialog box prompting me to edit the system profile location URL, accompanied by the following message: "A profile for this machine could not be found or retrieved. Check that you entered the correct location on the command line and try again ...". (the nfs URL is correct - entering variants of it such as replacing the server name with an IP address or pointing at the "default" file specifically does not help). I flipped to VT2 and manually attempted the NFS mount at the command line, and received the following error: mount.nfs: rpc.statd is nor running but is required for remote locking. Either use "-o nolocks" to keep locks local, or start statd. After I ran rpc.statd at the command line, I was able to manually mount the autoyast directory via NFS. I unmounted it, then returned to the VT with the graphical installer - which was now able to proceed.
*** This bug has been marked as a duplicate of bug 329791 ***
*** Bug 342587 has been marked as a duplicate of this bug. ***