> Right.  this is a simple, but serious, problem with all
> installboot-like programs (i.e. the one used on the alpha, and the
> ones used on other ports).
> 
> The problem is that 'installboot' needs read-write access to the
> partition containing a mounted file system.  That's a no-no.
> 
> The way to get around it (grab a trash can; you're going to vomit) is
> to use the disk's c partition, i.e. '/dev/rsd1c' for the example given
> above.  That happens to work since the disk handling code doesn't
> disallow read/write accesses to partitions overlapping mounted file
> systems (at least in this case) and because both 'a' and 'c' start at
> the same place on the disk.
> 
> 
> If you had your 'a' partition start somewhere else on the disk, this
> might not work, but then i'm not so sure that that NetBSD/alpha boot
> block would work, either.  8-)

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
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.
-or-
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.
-ben