> Thilo Manske <Thilo.Manske@HEH.Uni-Oldenburg.DE> said:
> On Sat, Feb 02 2002 at 15:45:09 -0700, Don Yuniskis wrote:
> >     Figured I could install the smaller drive at say ID 4 (the 400M
> > set at ID 3).  Boot the system to single user (for installboot).  Then
> >     disklabel -e sd1    # single partition
> >     newfs sd1a
> >     cd /usr/mdec
> >     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.

> Try this:
> mount /dev/sd1a /mnt
> # copy the second stage booter, if it's not already there.
> cp -p /usr/mdec/boot /mnt/boot
> # install bootblock and point it to the second stage booter
> /usr/mdec/installboot /mnt/boot /usr/mdec/bootxx /dev/rsd1a

To be specific, from single user mode:
    disklabel -e sd1    # single partition
    newfs sd1a
    mount /dev/sd1a /mnt
    cd /
    tar cpf - .[a-z]* [A-Za-ln-z]* | (cd /mnt; tar xvpf - )
# the funny set of patterns just avoids dragging /mnt into /mnt/mnt
# note that at this point the boot blocks exist at /boot/usr/mdec/boot and
/mnt/boot
# as well as at /usr/mdec/boot and /boot.  Further, I have cmp(1)'d them to
verify
# that they are, in fact, identical!
    mkdir /mnt/mnt
    /usr/mdec/installboot /mnt/boot /usr/mdec/bootxx /dev/rsd1a
    sync; sync
# not trusting umount to flush all buffers!
    umount /mnt
    sync; sync
    halt

Power down.  Change SCSI ID's as described previously.  Reboot.

This appears to have worked.  Thanks!

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)?  Or, does it store a path to the
boot blocks (though I guess smart enough to prune the
disk's mount point -- "/mnt" -- from that path!)?

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...)?

Though, the drive that is now sd1 (the 400M drive) is strapped
to NOT spin up when power is applied.  And the attempt to
probe/open the device times out.  (time to look for jumper info)

> >     mount /dev/rsd1a /mnt
> >     cd /
> >     tar cpf - <pattern> | ( cd /mnt; tar xvpf - )    # yes, easier ways
to
> > do this
> And faster, better. tar doesn't care about hardlinks (and other stuff).

The tar in {Open, Net, Free}BSD has no such problems.  You have
to PAY EXTRA if you want those bugs!!  :>

> I would use dump:
> cd /mnt;dump -0f /|restore -xf -

--don