> Thanks.  This being the case, I suggest that, at least in the interim,
> the examples on the installboot manual page and/or the example in the 
> Alpha port FAQ be changed to reflect reality.  For the longer term, it
> is probably a worthy goal to do one of the following - either

That's probably reasonable, but i think i'd like to fix it right...


> 1.  Not have installboot require that the root filesystem be mounted, and,
> in fact, have it require that it be run on an unmounted disk.  This would
> require putting some filesystem code into installboot (similar to the
> standalone filesystem stuff for systems that support things like a standalone
> fsck) and would also prohibit running installboot on the current root
> filesystem.

Of course, the latter condition make this somewhat unreasonable...


> 2.  Introduce some kind of new interface to the kernel for writing a boot
> block.  This is probably the real right thing to do for a number of reasons.
> The interface could be as simple as a pseudopartition that exists for all
> disks and is guaranteed to address the boot block and only the boot block.
> Also, really, no filesystem partition really ought to address the boot block,
> as the boot block is itself not part of any filesystem.  Probably in the
> future the 'a' partition of the disk should begin after the disk label and
> boot block and any related crud instead of at the beginning of the disk,
> although this would run counter to what the OEM Unix would do on those ports
> that have OEM Unixes to worry about.

While that's a nice sentiment, right now NetBSD/Alpha disks are
'compatible' with several other systems' (e.g. DU, probably
NetBSD/i386 w/o lots of bios partitions, and probably several other
little endian ffs-using systems) disk formats and i'd rather keep it
that way.

Also, putting this code into the kernel makes it harder to come up
with a machine-independent "disklabel and boot-block frobbing"
library, later.


It looks like 'the right solution' to this might not be too hard.
I'll look into it, and see what i can do...


chris