Managing NFS and NIS, 2nd Edition - Mike Eisler [104]
null domain name
invalid domain name
invalid boot parameters
or similar problems, verify that the host answering its broadcasts is using the same boot protocol and configuration files. See Section 15.3 for an example of invalid boot parameters.
Also ensure that the boot server exports the client's root and swap filesystems with the proper root mapping and access restrictions. In /etc/dfs/dfstab, both the root and swap filesystems should have the options:
rw=client,root=client
to limit access to the diskless client and to allow the superuser to write to the filesystems. If the swap filesystem is not exported so that root can write to it, the diskless client will not be able to start the init process to begin the single-user boot.
Missing /usr
After setting the host and domain names and configuring network interfaces in the boot process, a machine mounts its /usr filesystem. If there are problems with /usr, the boot process either hangs or fails at the first reference to the /usr filesystem. The two most common problems are not being able to locate the NFS server for /usr and attempting to mount the wrong /usr.
NIS cannot be started until after /usr is mounted, since client-side daemons like ypbind live in /usr. Generally, /usr is mounted from the boot server, so a diskless client needs its own name and its server's hostname in its /etc/hosts. If /usr is not mounted from the root/swap filesystem server, the /usr server's hostname must appear in the local hosts file as well. You may need as many as four different entries in the "runt" /etc/hosts file on a diskless client: its hostname, a localhost entry, the boot server's name, and the name of the /usr server.
Heterogeneous client/server environments create another set of problems. Clients of different architectures need their own /usr filesystems with executables built for the client's CPU, not the server's. The most obvious problem is when the client mounts the wrong /usr. If the executables on it were built for a different CPU, then the first attempt to invoke one of them produces a fairly descriptive error. However, if the /usr/platform directory is for the correct CPU architecture but doesn't contain the right kernel architecture (for example, Sun's sun4u and sun4m variants), then the client boots, but certain Unix utilities will not work. Processes that read the kernel or user address spaces, such as crash, are the most likely to break.
If you suspect that you're mounting the wrong /usr, first check the client's /etc/vfstab file to see where it gets /usr :
wahoo:/export/root/honeymoon - / nfs - - rw
wahoo:/export/swap/honeymoon - /dev/swap nfs - - -
wahoo:/export/exec/Solaris_2.7_sparc.all/usr - /usr nfs - - ro
In this example, we would check /export/exec/Solaris_2.7_sparc.all/usr on the server wahoo. The directories in /export/exec have names with this format: Solaris_ If the client and server do not have the same release and CPU architectures, the directories in /export/exec contain complete operating system releases. Three things can go wrong with this link-and-directory scheme: The links /export/exec/*/usr point to the wrong place. This is possible if you changed the architecture of the server but restored /export from a backup tape. Make sure that Solaris_2.7_sparc.all/usr links point to /usr only if the server is a SPARC running Solaris 7. You'll get "exec format" errors if you mount a /usr of the wrong architecture on the client. The /export/exec/* directories referenced by the clients don't exist. This is possible if you added