> well, let's give Sun some credit :-)
> 
> i am a fan of Sun's network boot path. basically it goes like
> this;
>
>   tftp is used to fetch the file "123.45.67.89.SUN3", which
>   we then execute. this file is the secondary boot loader.
>   (the bootrom can be very small -- i've written a lance-based
>   bootrom that is under 8K of m68k c/assembly code.)

This is a big plus.  TFTP isn't the greatest for things like kernels, but
with the secondary boot programs only a few 100K, it's not a big deal.

However, I should point out...
 
> notes:
> - why do you not want to tftp your kernel? well, most people
>   run tftpd in secure mode, ie. chroot'd to /tftpboot. if it
>   is chroot'd you cannot use symbolic links to the file
>   /export/clienta/root/netbsd. you must use a hard link. but if
>   /export happens to be a different filesystem... you're outa
>   luck.

But not really...remember, /tftpboot is just the default, you're 
perfectly free to say something like:

tftp dgram udp wait root /usr/sbin/in.tftpd	in.tftpd -s /export/kernels

Also, you can securely use a softlink for /tftpboot, since the chroot()
obviously chases this.  As long as /export/kernels is on the same fs, then 
you can hard link the kernels.

We did something like this at my old job hacking our own diskless client
support into a to be unnamed deficient Unix.  It was easy to write a boot
file with tftp, we really didn't feel like implementing the whole RPC/XDR
bit.

>   you do want the file "/netbsd" in the client's root filesystem
>   to be the same file as it booted from. otherwise ps/w/vmstat/iostat
>   & friends don't work.

And in NetBSD's default rc's you get the wrong kernel ID string in /etc/motd...

> boot -a can do the right thing with IP/path specifications.. it cannot
> handle hostnames. I have a vague memory that Wolfgang's bootrom code
> had BIND in it... that's not a very good idea though.

There is NIS...Sun's secondary boot files support it because you can use
hostnames in the bootparams map.  On the other hand, the initial prom
loader is extremely stupid about where it gets it's secondary boot file from.
Beware having two rarp daemons on your net, they better both have all the
needed boot files...

> - when the kernel comes up, it uses rarp/bootparams once again to
>   find out where what's going on, as described above by Adam.

On the otherhand, be careful.  The NIS make stuff lets you put just about
anything in these files (the bootparams map is one of the simple key/value
maps) and your clients can behave *very* strangely on very subtle errors
(extra returns and spaces, hostnames or dirs that don't exists or are 
unreachable).

-Mark


------------------------------------------------------------------------------