Re: rebuild 240v from scratch




Mike Dundas wrote:
> "tunla" <lars.tunkrans@xxxxxxxxxxxx> wrote in message
> news:1135851810.619907.211780@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> >
> > Mike Dundas wrote:
> >
> >> My plan was to partition mirror boot drive on "server b" to
> >> match our "server a" and ufsdump/ufsrestore over the network to the
> >> mounted mirror boot partitions on "server b". Once I had mirror boot
> >> disk bootable, I would boot from it and dd from one disk to the other.
> >>
> >> Once system restore was complete, I modified the vfstab on mounted
> >> mirror drive, /mnt/etc/vfstab, to point to correct disk and installed
> >> bootblk. I tried to boot from disk1 and the system failed to boot and
> >> panicked rebooting from primary boot disk. I have done some
> >> investigation and I think it has to do with the meta devices.
> >>
> >> boot message:
> >>
> >> Cannot open mirrored root device, error 19
> >> Cannot remount root on /pseudo/md@0:0,0,blk fstype ufs
> >>
> >> panic[cpu1]/thread=180e000: vfs_mountroot: cannot remount root
> >>
> >> Any help appreciated,
> >>
> >> Mike Dundas
> >
> > If your description of what took place is complete I would say
> > that the failure is due to that you did NOT create a new set
> > of METADEVICE databases on server b.
> >
> >
> > There is at least three things that must be present for a successful
> > volumemanager boot:
> >
> > /etc/system file must preload the MD devicedrivers and
> > the pointer to the metadevice rootfilesystem.
> >
> > /etc/vfstab must reference the metadevices.
> >
> > A valid and correct metadabase must exist that translates
> > the metadevice root-referens from /etc/system to a physical
> > disc/partition number.
> >
> > The error seems to say that the /etc/system file that you copied
> > over from server A with its root metadevice pointer could not
> > find a metadb on server B to resolve it to a physical partition.
> >
> > //Lars
> >
>
> I did "not" create a new set of devices, that is correct. I did modify the
> newly
> restored vfstab to reference the /dev/dsk/cXXXXXXX etc, and commented out
> the metadevice references. The reason for this was I am unfamiliar with
> metadevices
> and most of my systems have a boot drive and a mirror drive that I manually
> create/update
> every month with a script using the dd command.
>
> Must I therefore modify the /etc/system file. Is this possible by hand?
>
> What is the best practice when trying to restore this box. As it is right
> now I am trying to
> boot from the mirror drive on a server "B". Should I install Sol 10 copying
> partitions to
> match server "A", then use volume manager to create the mirror.
>
> The vendor who supplied the system wasn't much help. They had said to
> backup server "A"
> and restore to server "B". Unfortunatley, our netbackup software isn't
> compatable with
> Solaris 10 yet and no standalone DLT's avail anymore. I was using
> ufsdump/restore across network
> but I am having to restore to a mounted mirror drive. This seems rather
> convoluted!
>
>
> thanks for the advice can you now please answer my new questions?
>
> Thanks
>
> Mike Dundas


Mike,

I Understnad then that you need some sort of crash course in volume
manager
to be able to get this system back online Here it is as good as I can
make it.
READ All of this before you try to do it :-)

To recapitulate you replaced the c0t0d0 disk drive and was force
to restore
the c0t1d0 drive because the root partition was corrupted.
( this was a very bad series of events that led to both mirrors being
destroyed at the same time )

so to get this system back at all you reinstalled solaris on c0t0d0
and started
a restore of c0t1d0 by copying filesystems from an identical server .

Question now is in what state are your metadevice databases after all
this
has taken place.
I think you should Login to you working server A and run

metadb -i

and

metastat

this will show you what the config is supposed to look like.

Try to verify if the metadb parttions shown by metadb still exists
on
server B, try to run metadb -i on server B to check if there is a
remnant
of the previous metadb configuration left on the system.
If metadb dosent work at this point on server B use
prtvtoc /dev/rdsk/cXtXdXs2 to list the partion info on each disk.
It is likely that you have lost the metadb partitions on you two
system
disks at this point as you have reinstalled them and that they still
exist on
you two data disk.
Probably the easiest thing to to at this point is to erase the old
metadb
information that may still exist on server B

metadb -d -f devicename ( for all of them )

After you have removed the remainng metadb partitions I suggest that
you do exactly as you tried to do from the beginnig.
Copy the System partitions from server A to the second disc
on server B. Also create the metadb partition on disk2
Install the bootstrap on the second disk.
Then Edit /etc/vfstab and /etc/system so that all info regarding
Volume manager is deleted from these files ( i.e. a Vanilla /etc/system

and /etc/vfstab )
Then verify that you can boot standalone on server B's second disk.
Next copy the VTOC of the second disk to the first systemdisk

Probably: ( you actual devicenames may vary )

prtvtoc /dev/rdsk/c0t1d0s2 > /disk2.vtoc
fmthard -s /disk2.vtoc /dev/rdsk/c0t0d0s2

Now the Partions layouts should be identical.

nOW YOU NEED TO RESTABLISH THE metadb PARTITIONS



Read the metadb manual page carefully.

then probably

metadb -a -f c0t0d0sX c0t1d0sX C0t2d0sX c0t3d0sX

metadb -i should now show four valid metadb devices

then you need to create one way mirrors for all the active partitions
on the
systemdisk an maybe the datadisks to if these are to be mirrored.

READ the example section of the metainit(1M) man page carefully
You need to to this with the devicenames from you SECOND disk.

metainit -f d12 1 1 c0t1d0s0 ( for root )
metainit -f d22 1 1 c0t1d0s1 ( for SWAP ????)
metainit -f d32 1 1 c0t1d0s3 ( for /var ????)
..
..
metainit -d d10 -m d12 ( root's oneway mirror )
metainit -d d20 -m d22 ( SWAP oneway mirror )
metainit -d d30 -m d32 ( /var's oneway mirror )

A.S.O. for all you system partitions

then set the root device this uppdates /etc/system

metaroot d10

Check that /etc/system has been updated.

Manually update /etc/vfstab with the above entered metadevice names.
so that it looks similar to server A.

run metastat and check that everything seems O.K:

Shutdown and restart the server with disk2 as the boot disk.

Login and start the mirroring
setup the first disks devices

metainit -f d11 1 1 c0t0d0s0 ( for root )
metainit -f d21 1 1 c0t0d0s1 ( for SWAP ????)
metainit -f d31 1 1 c0t0d0s3 ( for /var ????)
..
..
metattach d10 d11 ( root's twoway mirror )
metattach d20 d21 ( SWAP twoway mirror )
metattach d30 d31 ( /var's twoway mirror )


Then do the same thing for you datadisks if nessesary.
Decide which of the datadisks is going to be treated as the good copy
and work from there.

If this is to heavy stuff for you, you will need to get SUN or some
other consultant
to do it.

Regards //Lars

.



Relevant Pages

  • Re: DiskSuite - puzzling issue
    ... this flag by saying "some claim that this is dangerous". ... > boot, where it will allow the system to boot with exactly 50% or more of ... > to remove the metadb replicas before shutting the machine down. ... on the replacement disk. ...
    (comp.unix.solaris)
  • Re: rebuild 240v from scratch
    ... >>> of METADEVICE databases on server b. ... >>> find a metadb on server B to resolve it to a physical partition. ... > It is likely that you have lost the metadb partitions on you two ... > you two data disk. ...
    (comp.unix.solaris)
  • Re: Unable to boot to existing 2003 server
    ... Formatted a floppy using 2003 server. ... Could not read from selected boot disk. ...
    (microsoft.public.windows.server.general)
  • Re: sbs2003 and mirrored drive failure. Help!
    ... So they replaced sbs with server std and exchange. ... boot from Ghost 2003 CD or Ghost boot floppies ... Remove the shadow disk from the server and keep it in a safe place ...
    (microsoft.public.windows.server.sbs)
  • Re: sbs2003 and mirrored drive failure. Help!
    ... Attach an external USB drive to the server ... boot from Ghost 2003 CD or Ghost boot floppies ... Remove the shadow disk from the server and keep it in a safe place ...
    (microsoft.public.windows.server.sbs)