David E Shapiro wrote:

> Hello,
>
> I want to exchange the root drive of my Solaris 2.4 server with a larger
> drive so that I can upgrade to Solaris 2.6.  I called SUN and they told me
> about their UFSBACKUP/UFSRESTORE program which backs up the boot
> information.  You need to backup the boot information, install the new

   To clarify, you are talking about ufsdump and ufsrestore.  (I have never
seenanything called ufsbackup.)  These programs deal with partitions, not
specifically 'boot information', and are used to backup and restore them.

> drive, and boot from the CD.  I would need to restore the boot information
> at this point.  Hmm.  How do I get access to the ADSM server to get the
> boot information if I do not have a root drive and booted from the OS from
> the CD? Do I need a floppy with the software on it?  I am not sure I would
> have network access at that point.

    The OS on the CD can be used to configure the network interfaces,
andpretty much everything else (just don't run out of RAM or use any commands
outside of the stuff available on the CD).  Now, because you have TWO disks,
you can get access to everything on the original disk AND everything on the
new disk.  You mount the disk onto (say) /mnt and have at it.  Very good thing

to recover from a bad password file or bad /etc/system, BTW.

      I would reccomend against doing a dd of /dev/rdsk/c0t0d0s2 to
your other disk, because it would overwrite the VTOC of the other disk (nasty)

and give you a disk of exactly the same size.  Using ufsdump and piping the
results
to ufsrestore would probably be ok, though.

    To explain more fully (assumes you're not using disksuite (ODS) or veritas
(VxFS)):
 1) attach both drives into the system
 2) boot into single user mode (boot -sr from the Forth ok prompt)

    Assuming that your boot disk is SCSI ID 0 on the motherboard controller,
and your other disk is SCSI ID 1 on the motherboard controller,

  3) using' format' set up the partitions on /dev/rdsk/c0t1d0sX to be the same
as the
     the partitions on the boot drive.  (Note that the X refers to the
partition number
     that you want to move over. DON'T EVER USE PARTITION NUMBER 2!!!)

  NB: If you need to change the partition sizes you cannot use 'ufsdump' or
'ufsrestore',
        as they are intimately familiar with the partition structure, and so
will need to explore
        other avenues.

        cd /mountpoint-to-copy
        ufsdump 0f - /dev/rdsk/c0t0ds0sX | (cd /mountpoint-to-restore-to ; \
             ufsrestore xf - )

   Make sure to do this for every partition you want to copy over.

   Further note that the above is taken from the man page for ufsdump.  I
haven't done
a ufsdump / ufsrestore this way (I do it all the time with tar, tho), so you
may need to
play with it a bit.

  4) To reset the boot block information, use the 'instalboot' command

    installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t1d0s0

   See the man page for installboot for more details.

 5) To test, do a 'sync ; sync; halt', then do a 'boot disk1' from the Forth
ok prompt.

   Anyway, as you can see, it's a pretty straightforward operation to do.
Well, ok, maybe not the most straightforward, but if that's what you want to
do,
that's the way to do it.

   Personally, I'd just install the drive into the machine, boot the machine
from the
OS CD, and install a new OS on the new drive.  After that, restore what you
want
from ADSM and away you go.  (Of course, like a previous respondent mentioned,
it's much faster and easier to remove the old disk, drop in the new one, and
do
a jumpstart install.  You can add in the old disk later (at a different SCSI
ID) to
get any files that you missed from there.)

   The backout plan for all of this is to avoid writing anything to your
original disk,
so that if you muck up the new (larger) disk, you can boot back to your old
system
and carry on.

   To do something like this with only one drive is (ahem) more complicated
and
left as an exercise to the reader.

>  Well, my question is whether ADSM has
> the ability to get me through a boot drive transfer for me?  What steps

>     You don't.  ADSM specifically doesn't do this -- it's outside of the
> design,
> and should properly not be a function of ADSM, IMHO.



> would I take before doing this task, and how would I do the restore using
> ADSM?

   After you restore the OS, use the dsmc client to restore the files you're
interested
in.  Again, I'll leave this as an exercise for the reader.


kells