On Tue, 29 Jan 2002, Matthew Sell wrote:

> I was confusing the Linux and NetBSD procedures. The Linux procedure
> downloads the kernel via MOP, and NetBSD downloads a bootloader.

Yeah, I think the Linux guys may run into more significant problems with
larger kernels someday.

> After the bootloader is grabbed from the network - what is the next
> step for it?

I think the newer 1.5.x bootloaders look for a BOOTP/DHCP server next,
and it may or may not fall back to using rarp/bootparamd if it can't get
it's BOOTP request answered.  In the older bootloaders, it defaulted to
using rarp and bootparamd.   The job of the bootloader is basically, to
get the NIC an IP address and some other vital information by using a
BOOTP request (name, IP address, NFS mountpoint for the kernel file).
Once it has its network info, I can NFS mount and bootstrap the kernel
image.

So... you're gonna need a DHCP server and an NFS server as well.
I think Linux still has hosed up NFSv3 support, so you may have to fight
with it a bit there.  In the early RedHat 6.x releases, you could
disable Linux's attempts to answer NFSv3 mount request (it would say
"okay" to a mount request, but the kernel didn't actually support NFSv3)
with an rpc.mountd flag that was something like "--no-nfs-version 3".
Then they moved a bunch of stuff into the kernel, and now I'm not sure
the same tricks work for the current releases of Linux.

Stick with the most recent versions of the bootloader for the current
NetBSD kernels.  There are some interactions in the handoff which
prevent the older bootloaders from working with newer kernels.  And
then somewhere in the 1.5 releases we had some bad MOPable bootloaders.
Was it 1.5, 1.5.1?  I'd have to check the mailing list archives.  I
*hope* that was  fixed for 1.5.2, but I've not really looked at the
netbooting stuff for VAX since sometime like around 1.4.1 or so.

-brian.