Solaris

Actually, it doesn't matter at this point I guess - I'm pretty sure you toasted the metadb info so you only have one course of action. The good news is if you haven't done anything else, you should be able to get your server back without to much trouble. (if someone else would double check my info below to insure we give CYPG good info here.)

boot single user from cdrom
ok boot cdrom -s
Once the server is up in single user, mount the /dev/rdsk/c0t0d0s0 which was /.
# mount /dev/dsk/c0t0d0s0 /a
# cd /a/etc
# cp vfstab vfstab.9999
# vi vfstab
Comment out any lines with /dev/md in them.
Add in the following:
/dev/dsk/c0t0d0s1 - - swap - no -
/dev/dsk/c0t0d0s0 /dev/rdsk/c0t0d0s0 / ufs 1 no logging
/dev/dsk/c0t0d0s6 /dev/rdsk/c0t0d0s6 /home ufs 2 yes logging

Save the file with wq
# cp system system.9999
# vi system
Remove any info about Disksuite - remove the lines between
* Begin MDD root info (do not edit)
and
* End MDD root info (do not edit)
Remove the lines between
* Begin MDD database info (do not edit)
and
* End MDD database info (do not edit)

Save the file with wq
#
# cd /
# umount /a
#fsck /dev/rdsk/c0t0d0s0
# eeprom
check that your boot device is equal to c0t0d0s0 - you may have look in format to check it
#sync;sync;halt
ok boot -s

This will set you up to hopefully have a system that boots - now all you need to do is recreate the mirrors again (including the metadb info). You will need to find an empty partition and put/allocate some space for the metadb info.

Suggest you put a comment in the vfstab that shows which partition holds the metadb so others will hopefully see it and not blow it away by mistake.

RTM, I'm not sure that your assumptions are correct. According to the Solstice DiskSuite User's Guide, page 272, if metadevice database replicas cannot be located the system requests the root password to allow maintenance...much like if a manual fsck was needed. cypg describes a system that is looping on reboot. That sounds more like the kernel won't load.

For the record I use slice 3 for my replica databases, not sure why I do. But anyway, this sentence bothers me: "I make a partition c0t0d0s7 and c0t1d0s7 with 30G each". 30G seems a bit large for a replica database. And this seems to imply that she used format to modify slice layout.

If your assumptions are correct, then your procedure does look good. Two points though... cypg may not be able to implement an instruction like: "This will set you up to hopefully have a system that boots - now all you need to do is recreate the mirrors again (including the metadb info). You will need to find an empty partition and put/allocate some space for the metadb info." But also, if she gets to this point, I would suggest a complete backup before attempting a re-mirror. If she already has a good backup that she trusts, then that's fine. But it seems that users seldom make a good backup prior to major surgery...especially when the surgery fails.

My take is that I would want to understand the disaster much more completely before I would be comfortable suggesting a solution.

well mate, the system will load the kernel, but when the ufs-boot will forceload the metadrivers from the /etc/system for the kernel initialization there will be an entry like:
rootdev:/pseudo/md@0:0,0,blk
so the kernel tries to load the next modules from a device which doesn't exist. panic --> next try --> panic --> next try -->

i would do the same, boot from CD, change the md entries in the vfstab back and delete the sds-forceloads and rootdev from the system file

Code:

forceload: misc/md_trans
forceload: misc/md_raid
forceload: misc/md_hotspares
forceload: misc/md_sp
forceload: misc/md_stripe
forceload: misc/md_mirror
forceload: drv/pcipsy
forceload: drv/simba
forceload: drv/glm
rootdev:/pseudo/md@0:0,0,blk

by the way, just for info: a sds database default length is 8192 blocks, that would be around 4 MB on a 512b LBA disk (-l would be the option from metadb to change that if your LBA is smaller) . i would recommend to make at least 3 copies/disk to prevent block errors, so we are on 12MB. usually i make 256MB slices, so i am prepared for VxVM aswell. the recommendation from sun for slice 7 is based on a suncluster enviroment, there the metadb's must be on slice 7 on the internal disks, and if you add a external disk to a metaset the db is automaticaly created on slice 7.

greetings PRESSY

Perderabo

My belief is that the Disksuite metadb was on slice 7 and she did not realize it - that she went in and put more space on slice 7, created a new filesystem, and blew away her metadb by mistake (no, she won't need 30G for the metadb). She was setting up a partition for Oracle and picked the wrong one, not realizing that maybe 2 or 3 cylinders put on slice 7 originally (that size is a guess too) was for the metadb. Once she rebooted, the system lost it's metadb (it would have been in memory when she made the change).

Also, if she hasn't done anything more than what was stated, she has two different drives with the same data - that's the backup. Actually, in doing this, she will learn that Disksuite is pretty easy to recover from when messing it up.

hi all,
i guess you guys are right. I do a newfs after I partition slice 7. The metadb mush has been destroy at this time.

Hi ,
The system able to boot up with the procedure provided. thank you very much for your help...