Subject: Re: NFS diskless boot improvement
To: None <firstname.lastname@example.org>
From: Theo Deraadt <email@example.com>
Date: 03/17/1994 01:55:25
I just finished moving, time to hop back in and reply to this
with my ideas. (then sleep :-)
> bootstrap program does whetaver is necessary to fetch kernel.
> nfs_mountroot() called revarp_whoami() to get client address,
> calls bootparam_whoami() and bootparam_getfile() to
> get root (swap) server addr and root (swap) pathname.
> then it calls nfs_getfh() on the root (swap) pathname.
> Then it does the normal nfs_mountroot() activities.
> Actually most of the above stuff is under nfs_boot()
> which is called by nfs_mountroot().
well, let's give Sun some credit :-)
i am a fan of Sun's network boot path. basically it goes like
- bootrom rarps to get it's IP address, say it finds it to be
tftp is used to fetch the file "188.8.131.52.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.)
- the secondary boot loader is more complicated, and since it
isn't in the rom can be quite a bit larger. it can use any
method it wants to
(1) find the root/swap filesystems
(a) bootparams (my favorite)
(c) say.. a file in the tftp directory?
(2) load the kernel
(a) use tftp (i think this is bad)
(b) use nfs (much preferred)
in any case the secondary server generally will rarp again.
(i think it does for the sun3, but doesn't for the sparc?)
you can use different secondary boot loaders for different
modes of operation.
- when the kernel comes up, it uses rarp/bootparams once again to
find out where what's going on, as described above by Adam.
- 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
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.
this is why sun uses NFS to fetch the kernel. the secondary
bootblock is smart (and can be large enough) to load the kernel
over NFS, from the exact same file.
> bootstrapping program doesn't have to understand symbol table
this is a large win.
> your bootstrap program can do something awful (like tftp)
> if you don't want to implement nfs (see libnetboot)
as said above, nfs is a much cleaner way to fetch the kernel.
> boot -a can do the right thing.
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.