Re: Netbooting a sparc64 (netbsd-6)

[Erik Fair <fair%netbsd.org@localhost>]

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 <fair%netbsd.org@localhost>