Prev: SMC and JAVA error
Next: Solaris 10 as openldap client
From: Sivakanth Mundru on 20 May 2005 06:07
M.H wrote:
> Hello everybody,
>
> 1. My /etc/vfstab is correct :
>
> /dev/vx/dsk/bootdg/rootvol /dev/vx/rdsk/bootdg/rootvol /
> ufs 1 no -
>
> 2. I'm using VxVM 4.0 so having bootdg in /etc/vfstab is normal.
>
> 3. Just to clarify something about my broblem:
> This is a test server with two disks ( boot(c0t0d0s0 &
> bootmirror(c0t1d0s0) disks). I want to test the "VERITAS[TM] Volume
> Manager 3.x/4.x: Installing Kernel patches" below (when i want to
> install a solaris kernel patch, i want to put the bootmirror disk
> OFFLINE anf if the patching goes wrong I can boot from the bootmirror

> disk as explained in the document).
>
> - 1st problem: When I offline the bootmirror(c0t1d0s0) disk ,
after
> I booting from cdrom, the /dev/dsk/c0t1d0s0 is not clean, I should
fsck
> and correct some problems.
> -2nd problem: When I reboot the system from the bootmirror disk
and
> before "Reattaching the plexes rootvol-01, swapvol-01, to the
relevant
> volume and resync." (see below) , the system drops on the maintenance

> shell because it can't mount /dev/vx/dsk/bootdg/rootvol as I said on
the
> my first mail.
>
> Thanks for the help.
>
>
> ======= Begin of the document=======
> Document Audience: SPECTRUM
>
> Document ID: 79356
>
> Title: VERITAS[TM] Volume Manager 3.x/4.x: Installing Kernel patches.
>
> Update Date: Tue Jan 04 00:00:00 MST 2005
>
> Products: VERITAS Volume Manager 3.5 Software, VERITAS Volume
Manager
> 4.0 Software
>
> Technical Areas: Administration
>
> Last Updated By: Fiona Turnbull
>
> Keyword(s):VxVM installing kernel patches
>
> Description:
>
> If a problem occurs during patching, a customer may wish to recover
from
> the mirrored rootdisk. Since all plexes will be in a clean state,
the
> procedure differs from recovering after disk failure.
>
>
> Document Body:
>
> When a customer installs Kernel patches in single-user mode, vxvol
will
> automatically resynchronize the data from the rootdisk to the
rootmirror
> as all plexes are in a clean state after a reboot.
>
> If there has been a problem during the patching process and the
customer
> needs to restore from the rootmirror, they need to ensure that this
> resync does not occur.
>
> In order to achieve this, each plex on the rootmirror needs to be
> off-lined. It is then possible to boot from its underlying
partitions
> of the root mirror and change the state of the rootdisk to detached.
> Then, booting from the mirror, vxvol will mirror the data from the
> rootmirror to the rootdisk.
>
> Below is the recommended procedure when splitting a VxVM mirror for
> patching.
>
> The plexes are defined as follows:
>
> rootvol-01
> swapvol-01
> var-01
> usr-01
>
>
> The rootmirror has the following plexes:
>
> rootvol-02 swapvol-02 var-02 usr-02
>
> 1. Split the mirror
>
> Offline the mirrors for the system volumes via the command line:
>
> # vxmend off rootvol-02
> # vxmend off swapvol-02
> # vxmend off var-02
> # vxmend off usr-02
>
> 2. Patch the software
>
> Bring the system to the correct run-level to perform the software
patching.
>
> 3. If successful, re-enable the mirrors and resync them:
>
> # vxmend on rootvol-02
> # vxmend on swapvol-02
> # vxmend on var-02
> # vxmend on usr-02
> # vxrecover -s
>
>
> 4. If unsuccesful, use the procedure below.
>
> *
> Boot the system
>
> OBP> boot cdrom -sw
>
>
> *
>
> After mounting the root partition of the rootmirror disk,
backup
> and edit the /etc/vfstab file. Replace the /dev/vx entries with
> underlying slice entries for all filesystems that reside on the
system disk.
> *
>
> Backup and edit the /etc/system file, removing the following
two
> entries:
>
> rootdev:/pseudo/vxio@0:0
> set vxio:vol_rootdev_is_volume=1
>
>
> *
>
> Touch the /etc/vx/reconfig.d/state.d/install-db file to
prevent
> VxVM from starting on the next boot from this disk.
> *
>
> Shutdown and explicitly boot from the mirror disk.
> *
>
> Start-up VxVM processes manually.
>
> # rm /etc/vx/reconfig.d/state.d/install-db
> # vxiod set 10
> # vxconfigd -d
> # vxdctl init <hostname>
> # vxdctl enable
>
>
> *
> Change the states of the volumes rootvol, swapvol and var so
that
> rootvol-01, swapvol-01, var-01 and usr-01 plexes are detached, and
> rootvol-02, swapvol-02, var-02 and usr-02 plexes are now the only
clean
> plex in each of the volumes.
>
> # vxplex -f det rootvol-01
> # vxmend on rootvol-02
> # vxmend fix clean rootvol-02
>
>
> *
> Restore the saved /etc/vfstab and /etc/system files.
>
> *
>
> Reboot the system, booting explicitly from the mirror disk
again.
> *
>
> Reattach the plexes rootvol-01, swapvol-01, var-01 and usr-01
to
> the relevant volume and resync.
>
> # vxplex att rootvol-01 rootvol-02
> # vxplex att swapvol-01 swapvol-02
> # vxplex att var-01 var-02
> # vxplex att usr-02 usr-02
> ===END of the Document===========
>
> BR
>
> haed.
>
> Groups Poster wrote:
> > M.H wrote:
> >
> >>Hi,
> >>
> >>When the server started, it drops on the maintenance shell because
> >
> > it
> >
> >>can't mount the /dev/vx/rdsk/bootdg/rootvol.
> >
> >
> > Can you please cut and paste what you have for rootvol in the
vfstab.
> > Is it maybe trying to mount the raw device?
> >
> >
> >
> >
> >>bash-2.03# mount /dev/vx/rdsk/bootdg/rootvol /mnt
> >>mount: /dev/vx/rdsk/bootdg/rootvol not a block device
> >
> >
> > Like Darren said you should mount the dsk and not rdsk.
> >
> >
> >
> >>bash-2.03# vxdiskadm
> >>VxVM vxdiskadm ERROR V-5-2-3540 Cannot create lock file
> >>/var/spool/locks/.DISKAD
> >>D.LOCK
> >
> >
> > Probably because /var isnt mounted.
> >
> >
> >>================
> >>bash-2.03# vxprint -Ath
> >>Disk group: rootdg
> >
> >
> > The vxprint looks ok. Can you post an output of vxdisk list too?
> >
> >
> >
> >>BR
> >>haed
> >
> >


If you are booted off of bootdisk disassociate the plexes corresponding
to bootmirror and vice versa.

Mount the slice 0 of the removed disk on /mnt and edit the
/mnt/etc/vfstab
to point the rootvol and swapvol to raw slices.

Comment the rootdev entries in /mnt/etc/system file.

This way even if your patches fail and if you are at ok prompt you can
just do a boot vx-bootmirror

Once you are up on the raw slices you can encapsulate the disk and
mirror the patched disk to get back to where the bootdisk was before
patch install to have a mirrored bootdisk until next patch schedule.

HTH,
S

From: Groups Poster on 20 May 2005 10:43
M.H wrote:

> 1. My /etc/vfstab is correct :
>
> /dev/vx/dsk/bootdg/rootvol /dev/vx/rdsk/bootdg/rootvol /
> ufs 1 no -
>
OK

> - 1st problem: When I offline the bootmirror(c0t1d0s0) disk ,
after
> I booting from cdrom, the /dev/dsk/c0t1d0s0 is not clean, I should
fsck
> and correct some problems.

That is quite possible and normal (as long as it doesnt find a zillion
errors a nd trash the filesystem)

> -2nd problem: When I reboot the system from the bootmirror disk
and
> before "Reattaching the plexes rootvol-01, swapvol-01, to the
relevant
> volume and resync." (see below) , the system drops on the maintenance

> shell because it can't mount /dev/vx/dsk/bootdg/rootvol as I said on
the
> my first mail.


In the document it asks you to edit the vfstab and system file and boot
off the underlying slices on the rootmirror. So there shouldnt be any
VX vols in the vfstab at this stage. After you vxmend the rootmirror as
described in the note change the system and vfsatb back and reboot. You
probably skipped the step about editing the files when booted off cd
and touching the install-db

See below:

> 4. If unsuccesful, use the procedure below.
>
> *
> Boot the system
>
> OBP> boot cdrom -sw
>
>
> *
>
> After mounting the root partition of the rootmirror disk,
backup
> and edit the /etc/vfstab file. Replace the /dev/vx entries with
> underlying slice entries for all filesystems that reside on the
system disk.
> *
>
> Backup and edit the /etc/system file, removing the following
two
> entries:
>
> rootdev:/pseudo/vxio@0:0
> set vxio:vol_rootdev_is_volume=1
>
>
> *
>
> Touch the /etc/vx/reconfig.d/state.d/install-db file to
prevent
> VxVM from starting on the next boot from this disk.
> *
>
> Shutdown and explicitly boot from the mirror disk.
> *
>
> Start-up VxVM processes manually.
>
> # rm /etc/vx/reconfig.d/state.d/install-db
> # vxiod set 10
> # vxconfigd -d
> # vxdctl init <hostname>
> # vxdctl enable
>
>
> *
> Change the states of the volumes rootvol, swapvol and var so
that
> rootvol-01, swapvol-01, var-01 and usr-01 plexes are detached, and
> rootvol-02, swapvol-02, var-02 and usr-02 plexes are now the only
clean
> plex in each of the volumes.
>
> # vxplex -f det rootvol-01
> # vxmend on rootvol-02
> # vxmend fix clean rootvol-02
>
>
> *
> Restore the saved /etc/vfstab and /etc/system files.
>
> *
>
> Reboot the system, booting explicitly from the mirror disk
again.
> *
>
> Reattach the plexes rootvol-01, swapvol-01, var-01 and usr-01
to
> the relevant volume and resync.
>
> # vxplex att rootvol-01 rootvol-02
> # vxplex att swapvol-01 swapvol-02
> # vxplex att var-01 var-02
> # vxplex att usr-02 usr-02
> ===END of the Document===========
>
>

From: Darren Dunham on 20 May 2005 10:53
M.H <haed98(a)excite.com> wrote:
> 3. Just to clarify something about my broblem:
> This is a test server with two disks ( boot(c0t0d0s0 &
> bootmirror(c0t1d0s0) disks). I want to test the "VERITAS[TM] Volume
> Manager 3.x/4.x: Installing Kernel patches" below (when i want to
> install a solaris kernel patch, i want to put the bootmirror disk
> OFFLINE anf if the patching goes wrong I can boot from the bootmirror
> disk as explained in the document).

Heh.

What I do, is pull the bootmirror. No vx commands, no changing
/etc/vfstab, nothing...

If there's a problem, I know the mirror disk has a valid, *bootable*
configuration. If I were to stop the mirror via commands, I'd have to
do a lot more work to get that to happen (clean up /etc/system,
/etc/vfstab on the disk, no vxvm running...)

Now if the patches work, great. Stick the disk back in, return it to
the diskgroup and let it resynchronize.

Want to back the patches out? Pull rootdisk and reintroduce
rootmirror. Boot from rootmirror, verify everything is good and return
the rootdisk to the configuration and resynchronize.

I had an E10000 without cdrom and without bootable network (OS couldn't
boot over a 'ge' device at the time). I had to go back and forth
between some disks and this worked *very* well.

--
Darren Dunham ddunham(a)taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
From: Sivakanth Mundru on 20 May 2005 20:48

Darren Dunham wrote:
> M.H <haed98(a)excite.com> wrote:
> > 3. Just to clarify something about my broblem:
> > This is a test server with two disks ( boot(c0t0d0s0 &
> > bootmirror(c0t1d0s0) disks). I want to test the "VERITAS[TM] Volume

> > Manager 3.x/4.x: Installing Kernel patches" below (when i want to
> > install a solaris kernel patch, i want to put the bootmirror disk
> > OFFLINE anf if the patching goes wrong I can boot from the
bootmirror
> > disk as explained in the document).
>
> Heh.
>
> What I do, is pull the bootmirror. No vx commands, no changing
> /etc/vfstab, nothing...
>
> If there's a problem, I know the mirror disk has a valid, *bootable*
> configuration. If I were to stop the mirror via commands, I'd have
to
> do a lot more work to get that to happen (clean up /etc/system,
> /etc/vfstab on the disk, no vxvm running...)
>
> Now if the patches work, great. Stick the disk back in, return it to
> the diskgroup and let it resynchronize.
>
> Want to back the patches out? Pull rootdisk and reintroduce
> rootmirror. Boot from rootmirror, verify everything is good and
return
> the rootdisk to the configuration and resynchronize.
>
> I had an E10000 without cdrom and without bootable network (OS
couldn't
> boot over a 'ge' device at the time). I had to go back and forth
> between some disks and this worked *very* well.
>
> --
> Darren Dunham
ddunham(a)taos.com
> Senior Technical Consultant TAOS
http://www.taos.com/
> Got some Dr Pepper? San Francisco, CA bay
area
> < This line left intentionally blank to confuse you. >

Nothing better than yanking out a disk to get Veritas Suppressed on a
mirrored bootdisk.

S

From: Darren Dunham on 23 May 2005 12:33
Sivakanth Mundru <mundru.sun(a)gmail.com> wrote:
> Nothing better than yanking out a disk to get Veritas Suppressed on a
> mirrored bootdisk.

What do you mean by 'suppressed' here?

--
Darren Dunham ddunham(a)taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: SMC and JAVA error
Next: Solaris 10 as openldap client