SUMMARY: sol251 + sds40 --> sol26 + sds4x recommendations

From: David Thorburn-Gundlach (david@bae.uga.edu)
Date: Fri Mar 06 1998 - 12:58:13 CST


Hi, folks --

At long last, after going back and forth with Sun on this to get the
right steps, I've worked out a fairly stable and reliable procedure.
This summary is a little long, but packed full of detail :-)

...and then David Thorburn-Gundlach said...
% Hi, folks --
%
% I saw a couple of archived summaries that touched on this, but nothing
% exact -- and I tend to be the nervous type :-) We have a server
% running Solaris 2.5.1 and Solstice DiskSuite 4.0 to manage the mirrored
% and logged stripes out on an SSA, and we need to bump it to Solaris
% 2.6. I have heard, though not been able to verify, that 2.6 requires
% 4.1; is that so? Meanwhile, what is the best way to go from 2.5.1 to
% 2.6 (via a fresh install, rather than an "upgrade", too) and retain the
% metadevice information? Is it as simple as "back off
% /etc/opt/SUNWmd/md.tab, do the reinstall and pkgadd, put md.tab in
% place, and run metainit"?
%
%
% Thanks; I will summarize. Marc, thanks for your info :-)
%
% :-D

Yes, 4.1 is required for Solaris 2.6, and it's almost as simple as
"back off md.tab". Here's how it works. Since I was changing the
layout of the internal drive (and, therefore, its mirror), I didn't
really care about anything that was on c0. As an additional challenge,
however, my ssa controller somehow changed from c2 to c1 (I guess that
should read "was somehow c2, and was reset to c1") during the jumpstart,
so I had to go back through and change all instances of "c2" to "c1" in
my kept metastat output. We had a metaset (srg2) defined, too, so we
had to go into that level of definition below.

Of some interest is the note that you must either create a /.rhosts
entry that allows you to rsh back into the machine *or* add root to
group 14 (sysadm). The former was required because the metaset
command from step 9 below actually makes a rsh-type connection; after
enough people complained about not wanting the security hole, it
seems, Sun added the gruop 14 functionality in DiskSuite 4.1. Of
course, this wasn't documented in the procedure from Sun :-)/2 so I
had a small heart attack in the middle of the procedure!

Of more interest is the fact that you can avoid a complete reformat
when using "metainit -a" to add drives; this took us a few letters back
and forth to straighten out :-) Essentially, metainit will format if
metaset needs to relocate or resize slice 7 (where it likes to keep the
state DBs), or if any slice (typically slice 2, but could be any slice
for this case) exists which has a TAG of 5 ("backup" or "overlap").
However, if this "backup" slice is not actually being used by the
metadevice, it can safely be zeroed out (if necessary) and have its
TAG reset; you can do this with format (change to "unassigned").

Of some interest as well is the fact that metainit, upon finding two
sides of a mirror in md.tab, assumes that they were shut down cleanly
and doesn't attempt to consider one the "master" and sync to the other
(unless, I suppose, it finds errors when it goes to compare the two,
but I don't know enough about those guts to tell). As such, metainit
will complain like a stuck pig in step 12 below, but it will succeed
without trying to rewrite one side of the mirror.

What I did was:

- dump `metaset`, `metastat -p`, `metastat -s srg2 -p`, `metadb -i`,
`metadb -s srg2 -i` (just for good measure), /etc/system, md.tab, and
/etc/vfstab to another machine (I actually didn't need `metadb -i`,
since I rebuilt the root from scratch and metainit will detect the
state databases out on the array)

- back up to tape twice, of course

- install Sol26 and SDS41, leaving slice 7 with 5 unmounted cylinders;

- format c0t1d0 as c0t0d0
        prtvtoc /dev/rdsk/c0t0d0s2 | fmthard -s - /dev/rdsk/c0t1d0s2

- create state DBs on each slice 7
        /usr/opt/SUNWmd/sbin/metadb -a -f -c 2 c0t0d0s7
        /usr/opt/SUNWmd/sbin/metadb -a -c 2 c0t1d0s7

- encapsulate and mirror the root drive
        /usr/opt/SUNWmd/sbin/metainit -f d11 1 1 c0t0d0s0
        /usr/opt/SUNWmd/sbin/metainit d12 1 1 c0t1d0s0
        /usr/opt/SUNWmd/sbin/metainit d10 -m d11
        /usr/opt/SUNWmd/sbin/metaroot d10
        lockfs -fa
        reboot
        /usr/opt/SUNWmd/sbin/metattach d10 d12
        <wait for resync to finish; metattach returns immediately>

- use format to clear s2 cylinders and TAG on all drives that needed it

- recreate metaset (after adding root to group 14)
        - metaset -s srg2 -a -h gsun84

- add the disks from the old metaset to srg2 (after changing c2 -> c1)
        - metaset -s srg2 -a cXtXdXsX ...

- append the old `metaset -s srg2 -p` to /etc/opt/SUNWmd/md.tab

- metainit everything (note: dirty and noisy; should metainit things by
hand, probably, but OK as noted above)
        - metainit -s srg2 -a

- modify /etc/vfstab and add old mount points

- reboot and check everything to make sure you're happy (and I was)

The procedure, as sent by Sun (and mildly tweaked to make it fit in 80
columns):

========= ========= ========= ========= ========= ========= =========

1) If the boot drive is mirrored or under DiskSuites control, clear any
mirros and submirrors associated with those devices. i.e. / /usr
/var /usr/openwin /export/home swap. Modify the vfstab to
reflect those changes and remove the line from the /etc/system file
that looks like the following:

        rootdev:/pseudo/md@******

This will tell DiskSuite that root is no longer a met adevice to boot
off of.

metaclear -f <metadevice number>

example: metaclear -f d0 (then clear the submirrors that were
attached to the mirror)

2) Print out the current metasets that you currently have configured
with the metaset command.

# metaset >> file

You will want to keep a copy of this output to recreate the metasets
later.

3) Use the metastat -p command to print out the non-metaset DiskSuite
configurat ion of the system. Then use the metastat -s <setname> -p
command for each metaset gott en from the metaset command to print out
each metasets configuration.

# metastat -p > file (preferrably to the /etc/opt/SUNWmd/md.tab file if
this has n't been modified by anyone. By default this file contains
lines that are all commented out)
# metastat -s <setname> -p >> file (md.tab)

NOTE: each metastat (-s) -p should be redirected to a file, preferrably
appended into the same file (md.tab). You will need this info. to
rebuild your data later.

4) Use the metadb -i command to print out the locations of all the
database repl icas on the system.

# metadb -i

NOTE: You do not need to print out the ones for the metaset because
DiskSuite will create the replicas in the metaset in the slice 7 area
on the disk using an algorithim function that is built in telling it
when and where to create the replicas.

5) Save copies of all files created and possibly create printouts
(including the /etc/vfstab file)

6) Install the OS

7) install the DiskSuite 4.1 software

8) Recreate the database replicas from the metadb -i (assuming
controller number s don't change)

# metadb -f -a /dev/dsk/c0t0d0s7
# metadb -f -a /dev/dsk/c0t1d0s7

9) Recreate the metasets that were created:

# metaset -s <setname> -a -h <hostname>

10) Add the disks that belonged to the disksets back to the disksets
from the me tset output:

# metaset -s <setname> -a cxtxdx cxtxdx cxtxdx cxtxdx cxtxdx cxtxdx

11) Append the information from the metastat -p and metastat -s
<setname> -p to the new md.tab file.

cat metastat-p >> /etc/opt/SUNWmd/md.tab
.....

12) Run metainit -a to recreate all non metaset metadevices then
metainit -s <se tname> -a to recreate your metaset metadevices.

# metainit -a
# metainit -s <set name> -a

13) Run metaroot on the root metadevice if root was mirrored

14) Modify the vfstab to mount up all metadevices including the
bootdrive metade vices

15) Reboot the system

16) Verify all data is back and DiskSuite reports no errors.

========= ========= ========= ========= ========= ========= =========

Whew!

:-D

-- 
David Thorburn-Gundlach         * It's easier to fight for one's principles
(play) david@bae.uga.edu        * than to live up to them. -- fortune cookie
(work) david_thorburn-gundlach@groton.pfizer.com   Helping out at Pfizer
http://www.bae.uga.edu/other/david/



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:33 CDT