Subject: Re: Diskless boot weirdness
To: maximum entropy <entropy@zippy.bernstein.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-i386
Date: 05/20/1997 00:24:08
Maximum entropy <entropy@zippy.bernstein.com> writes:

>I was not able to install the newer boot blocks from
>/sys/arch/i386/stand/biosboot.  Here's what I did...

The right way to install the new bootblocks is to make, install, and
run installboot.  It Just Works.

>This leads me up to another problem I ran into a while back but
>ignored because I assumed I had done something wrong...  I'm playing
>with the idea of generating a boot prom for one of my 3c509's so that
>I can do a full diskless boot without a kernel floppy.  When I tried
>to build the boot prom (/sys/arch/i386/stand/netboot), genprom
>complained that the boot image was too large (it was somewhere in the
>neighborhood of 33k, and the rom size is 32k.)  Did something grow
>very large in one of the stand libraries that suddenly broke all this
>stuff?


I think libz was added after the netboot code was imported.  Libz is
non-negligible given a 32k limit. You could try reconfiguring the
Makefiles to not include libz.

Alterntively, you could try adding a NO_TWIDDLE ifdef to stand.h:
#ifdef NO_TWIDDLE
# define twiddle() do {} while (0)
#else
	/* twiddle prototype
#endif

That should buy back nearly 100 bytes, still not quite enough.

nm says that the netboot prom is using NFS to read in the kernel
image.  If it were me, I'd consider nuking both the progress twiddles
code and the NFS symlink-following code: (put ifdefs around
nfs_readlink() in nfs.c, and round the block containing the call:
return an error there instead.)

I suspect it comes down to personal taste which is more useful in a
boot-PROM: following symlinks,  booting uncompressed kernels, or
<insert function of your choice from netboot.list>