>der Mouse <mouse@Rodents.Montreal.QC.CA> said:


> >>>     installboot boot bootxx /dev/rsd1a
> >> That's wrong, see installboot(8) for details.
> > I've tried several different incantations... including
> > /usr/mdec/installboot /usr/mdec/boot /usr/mdec/bootxx /dev/rsd1a
> > None work.
> 
> 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...)
 
> You need to copy /usr/mdec/boot to the boot partition and then give
> installboot the path to the copy.

It *is* on the booted partition...
 
> You presently have to have the filesystem mounted.  This is a
> conceptual crock and was presumably done because it makes installboot's
> code significantly simpler.  I've some hacks to installboot that I
> suspect may help with this; I need to test them.  (I think mrg has a
> copy of them, and was making noises about getting them into
> installboot, originally for cross-compile purposes I think.)
> 
> >     tar cpf - .[a-z]* [A-Za-ln-z]* | (cd /mnt; tar xvpf - )
> > # the funny set of patterns just avoids dragging /mnt into /mnt/mnt
> 
> Heh.  It also avoids all dotfiles not beginning with a letter, and

I happen to know what's on *my* disk  :>  so .[a-z] *will* catch
everything there!  :>  (give me *some* credit... :>  I'm not trying to
write a *general purpose* solution... just "get it done"! )

> other stuff beginning with m, as well as everything beginning with
> [^.a-zA-Z]...not that / usually contains such stuff.  Usually. :->

Above patterns get everything on the disk...
 
> Now, if you were using my tar, it'd be
> 
> tar cf - * .* -X . -X .. -X mnt | ...
> 
> or even just
> 
> tar cf - . -X ./mnt | ...
> 
> though that has the additional effect of copying the mode bits from the
> old root to the new.  (This can be good or bad, depending on what you
> want.)
> 
> See ftp.netbsd.org:/pub/NetBSD/misc/mouse/tar/ if you're interested in
> my tar.
> 
> >     /usr/mdec/installboot /mnt/boot /usr/mdec/bootxx /dev/rsd1a
> [...]
> > This appears to have worked.  Thanks!
> 
> Note that installboot here was given the path to the _installed_ copy
> of boot, not the /usr/mdec copy.

The "installed copy" was also present in /usr/mdec/boot* (see above)

> > So, does installboot determine the location of the boot blocks by
> > examining where *physically* it is located on the disk (i.e.
> > "/mnt/boot" in this case)?
> 
> Yes.

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?

> > I.e. why did my attempts fail?  And, more importantly, if I *move*
> > "/boot" to a different physical place on the media (i.e. backup +
> > restore), will the bootstrap no longer be able to find it (even if it
> > is in the same logical place in the filesystem hierarchy...)?
> 
> Yes; you will need to rerun installboot if you do anything that makes
> the data blocks move.

OK.  Of course, someone has added these little caveats to the man 
page, *right*???

> You can mv the file anywhere on the partition and it will be just fine;
> keeping it in /boot is purely a human convention.  You can even remove
> it, if you're crazy enough, and it'll continue to work until the data
> blocks it used to occupy happen to get reused for something else.
> 
> But destroy it and recreate it, even with something like "cat
> /usr/mdec/boot > /boot" (which will truncate it to zero size and free
> all the blocks, allocating new and possibly different blocks for the
> new contents), and you're asking for trouble unless you rerun
> installboot.  As you can see from the above, it may appear to work if
> you skip the installboot, but as soon as the data blocks whose numbers
> installboot shoved into the boot program get reused (which might even
> be for the new version), it will start falling over.

Understood.  Presumably this is because the boot loader (first stage) 
doesn't have enough smarts to walk the file system?

--don