> 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