diskless man page on MirBSD

Man page or keyword search:  
man Server   6113 pages
apropos Keyword Search (all sections)
Output format
MirBSD logo
[printable version]

DISKLESS(8)		 BSD System Manager's Manual		   DISKLESS(8)

NAME
     diskless - booting a system over the network

DESCRIPTION
     The ability to boot a machine over the network is useful for diskless or
     dataless machines, or as a temporary measure while repairing or re-
     installing filesystems on a local disk. This file provides a general
     description of the interactions between a client and its server when a
     client is booting over the network. The general description is followed
     by specific instructions for configuring a server for diskless Sun
     clients.

OPERATION
     When booting a system over the network, there are three phases of in-
     teraction between client and server:

     1.	  The PROM (or stage-1 bootstrap) loads a boot program.
     2.	  The boot program loads a kernel.
     3.	  The kernel does NFS mounts for root and swap.

     Each of these phases are described in further detail below.

     In phase 1, the PROM loads a boot program. PROM designs vary widely, so
     this phase is inherently machine-specific. Sun and Motorola machines use
     RARP to determine the client's IP address and then use TFTP to download a
     boot program from whoever sent the RARP reply. HP 300-series machines use
     the HP Remote Maintenance Protocol to download a boot program. Other
     machines may load a network boot program either from diskette or using a
     special PROM on the network card.

     In phase 2, the boot program loads a kernel. Operation in this phase
     depends on the design of the boot program. The boot program:

     2.1  gets the client IP address using RARP.
     2.2  gets the client name and server IP address by broadcasting an RPC /
	  BOOTPARAMS / WHOAMI request with the client IP address.
     2.3  gets the server path for this client's root using an RPC /
	  BOOTPARAMS / GETFILE request with the client name.
     2.4  gets the root file handle by calling mountd(8) with the server path
	  for the client root.
     2.5  gets the kernel file handle by calling NFS lookup on the root file
	  handle.
     2.6  loads the kernel using NFS read calls on the kernel file handle.
     2.7  transfers control to the kernel entry point.

     In phase 3, the kernel does NFS mounts for root and swap. The kernel re-
     peats much of the work done by the boot program because there is no stan-
     dard way for the boot program to pass the information it gathered on to
     the kernel. The procedure used by the kernel is as follows:

     3.1  The kernel finds a boot server using the same procedure as described
	  in steps 2.1 and 2.2 above.
     3.2  The kernel gets the NFS file handle for root using the same pro-
	  cedure as described in steps 2.3 through 2.5 above.
     3.3  The kernel calls the NFS getattr function to get the last-modified
	  time of the root directory, and uses it to check the system clock.
     3.4  If the kernel is configured for swap on NFS, it uses the same
	  mechanism as for root, but uses the NFS getattr function to deter-
	  mine the size of the swap area.

CONFIGURATION
     Before a client can boot over the network, its server must be configured
     correctly. This example will demonstrate how a Sun client might be con-
     figured -- other clients should be similar.
     Assuming the client's hostname is to be "myclient",

     1.	  Add an entry to /etc/ethers corresponding to the client's Ethernet
	  address:

		8:0:20:7:c5:c7		myclient

	  This will be used by rarpd(8).

     2.	  Assign an IP address for myclient in your /etc/hosts or DNS data-
	  base:

		192.197.96.12		myclient

     3.	  If booting a Sun or Motorola client, ensure that /etc/inetd.conf is
	  configured to run tftpd(8) in the directory /tftpboot.

	  If booting an HP 300-series machine, ensure that /etc/rbootd.conf is
	  configured properly to transfer the boot program to the client. An
	  entry might look like this:

		08:00:09:01:23:E6	SYS_UBOOT	# myclient

	  See the rbootd(8) manual page for more information.

     4.	  If booting a Sun or Motorola client, install a copy of the appropri-
	  ate diskless boot loader (such as boot from the root directory of
	  the MirOS sparc tree) in the /tftpboot directory. Make a link such
	  that the boot program is accessible by a file name composed of the
	  client's IP address in HEX, a dot, and the architecture name (all
	  upper case). For example:

		# cd /tftpboot
		# ln -s boot C0C5600C.SUN4

	  Some architectures, such as the Sun3 and Ultrasparc machines, do not
	  append the architecture name. It this case, the name would be just
	  C0C5600C. The name used is architecture dependent, it simply has to
	  match what the booting client's PROM wishes to it to be. If the
	  client's PROM fails to fetch the expected file, tcpdump(8) can be
	  used to discover which filename the client is trying to read.

	  If booting an HP 300-series machine, ensure that the general purpose
	  boot program SYS_UBOOT (which may be called netboot.lif before in-
	  stallation) is installed in the directory /usr/mdec/rbootd.

     5.	  Add myclient to the bootparams database /etc/bootparams:

		myclient  root=server:/export/myclient/root \
			  swap=server:/export/myclient/swap

	  Note that some bootparam servers are somewhat sensitive. Some re-
	  quire fully qualified hostnames or partially qualified hostnames
	  (which can be solved by having both fully and partially qualified
	  entries). Other servers are case sensitive.

     6.	  Build the swap file for myclient:

		# mkdir /export/myclient
		# cd /export/myclient
		# dd if=/dev/zero of=swap bs=1m count=120

	  This creates a 120 Megabyte swap file.

     7.	  Populate myclient's / filesystem on the server. How this is done
	  depends on the client architecture and the version of the OpenBSD
	  distribution. It can be as simple as copying and modifying the
	  server's root filesystem, or perhaps you need to get those files out
	  of the standard binary distribution.

     8.	  Export the required filesystems in /etc/exports:

		/usr -ro myclient
		# for SunOS:
		# /export/myclient -rw=myclient,root=myclient
		# for OpenBSD:
		/export/myclient -maproot=root -alldirs myclient

	  If the server and client are of the same architecture, then the
	  client can share the server's /usr filesystem (as is done above). If
	  not, you must build a properly fleshed out /usr partition for the
	  client in some other place.

	  If your server was a sparc, and your client a sun3, you might create
	  and fill /export/usr.sun3 and then use the following /etc/exports
	  lines:

		/export/usr.sun3 -ro myclient
		/export/myclient -rw=myclient,root=myclient

     9.	  Copy and customize at least the following files in
	  /export/myclient/root:

		# cd /export/myclient/root/etc
		# cp fstab.nfs fstab
		# cp /etc/hosts hosts
		# echo myclient > myname
		# echo inet 192.197.96.12 > hostname.le0

	  Note that "le0" above should be replaced with the name of the net-
	  work interface that the client will use for booting.

     10.  Correct the critical mount points in the client's /etc/fstab (which
	  will be /export/myclient/root/etc/fstab) i.e.,

		myserver:/export/myclient/root / nfs rw 0 0
		myserver:/usr /usr nfs rw 0 0

FILES
     /etc/ethers       Ethernet addresses of known clients
     /etc/bootparams   client root and swap pathnames
     /etc/exports      exported NFS mount points
     /etc/rbootd.conf  configuration file for HP Remote Boot Daemon
     /tftpboot	       location of boot programs loaded by the Sun PROM
     /usr/mdec/rbootd  location of boot programs loaded by the HP Boot ROM

SEE ALSO
     bootparams(5), ethers(5), exports(5), mountd(8), nfsd(8), rarpd(8),
     rbootd(8), reboot(8), rpc.bootparamd(8), tftpd(8)

MirOS BSD #10-current		March 3, 2008				     2
[top]

List of man pages available for MirBSD

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net