Re: Netbooting a sparc64 (netbsd-6)
Erik Fair <[email protected]>
| Newsgroups | gmane.os.netbsd.ports.sparc64 |
|---|---|
| Message-ID | <[email protected]> |
There are two ways to deal with this for Suns:
the old way: RARP + bootparamd
the new way: DHCP (looks like your sparc64 is trying new way first)
The variants of firmware I've netbooted over the years have taught me that firmware is kinda particular about what it gets back from the network as responses to its queries.
I'll describe new way, with DHCP:
key dhcp parameters:
option next-server 1.2.3.4 # or a hostname; this is where secondary boot will be TFTP'd from
server-name "a-hostname-string-here-for-nfs-mounts-usually-short";
host net-boot-client-host {
hardware ethernet xx:xx:xx:xx:xx:xx; # the client's MAC
fixed-address 4.5.6.7; # or a hostname
option root-path "/an/nfs/exported/root/for/this/host"
}
Your netboot server [1.2.3.4] will have to have the NetBSD/sparc64 netboot secondary booter available for TFTP (configure TFTP in /etc/inetd.conf) and it will have to be named by the client's assigned IP address ... in capital hexadecimal. Once your netboot client has its IP address, you'll see the TFTP requests in your server's log.
I like to set up TFTPd so that it gets every unadorned filename from /tftpboot, e.g.
tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpboot
and then I set up that directory to have subdirs for each host type I've got files for, e.g. /tftpboot/sparc64/ and the netboot file goes in there, and then I symlink the file in /tftpboot, thus:
lrwxr-xr-x 1 root wheel 19 May 23 2007 0A000205 -> sparc64/ofwboot.net
That way it's easy to see what a given file actually is.
The NetBSD secondary booter fetches /netbsd from the root with NFS, looking for, e.g. a-hostname-string-here-for-nfs-mounts-usually-short:/an/nfs/exported/root/for/this/host/netbsd (and then netbsd.gz and then netbsd.old and then ...)
It's possible to make this more flexible (e.g. the NFS/DHCP/boot server figures out what the client is and feeds it dynamic IP addresses out of a pool, plus whatever booter it needs), but I've found it easier to maintain fixed address+name+NFS mounts mappings myself, manually.
Your netboot server's logs are your friends. They should tell you what the client is asking for. Failing that, there's always tcpdump.
Erik <[email protected]>