> der Mouse <mouse@Rodents.Montreal.QC.CA> claimed:
> >> This looks as though you're naming the "boot" in /usr/mdec.  That
> >> won't work (unless /usr/mdec is actually in your boot partition).
> > Yes.  A single partition -- "/" (drive is too small to worry about
> > splitting it up...)
> 
> Then I have no idea why it failed.  What happened when you tried to
> boot from the resulting partition?

Varied.  But, always consistent with "crud" getting dragged in
and executed (aren't any sanity checks done on the image as it
is loaded??? even a magic number test???).  For example:
    Instruction Access Exception
(sorry, may be misremembering this... notes are in the other room)
 
> > So, if I rm it and add it again later (i.e. so it most likely ends up
> > in different sectors, etc.) then I am screwed?
> 
> Yes, unless you rerun installboot after you recreate it and before you
> next try to boot from that disk.

Dunno.  I tried several different variations on setting up the boot
blocks and, undoubtedly, screwed things up along the way...

> Or unless you're lucky and the data blocks don't happen to get
> overwritten.  I recommend you not count on that. :-)
> 
> > Presumably this is because the boot loader (first stage) doesn't have
> > enough smarts to walk the file system?
> 
> At present it doesn't, correct.  I've heard rumblings that someone is
> trying to pack enough smarts into it for it to do so; I don't know how
> far that effort has gone.  (7.5K isn't really much room, even when you
> don't have to do the actual disk I/O yourself.)

I guess that's relative... designed a LORAN-C position plotter in *12K*
(and that had to do *all* the I/O as well  :>)

Looks like the short-term fix is to update the man page to be a bit more
vocal about what is happening and the caveats involved...

--don