[SunHELP] RE: [Veritas-vx] Booting different Solaris versions with Veritas rootdg's

DAUBIGNE Sebastien - BOR SDaubigne@bordeaux-bersol.sema.slb.com sunhelp at sunhelp.org
Fri Dec 28 11:11:51 CST 2001


As far as I understand the "vxdctl" manpage, it should be possible
to boot each OS/disk without refreshing the timestamps.

You can tell VxVM where to search the rootdg disks, instead of
scanning every disk and taking the most recent GID.

>From "man vxdctl" :
The volboot file also contains a list of disks  to  scan  in
search of the rootdg disk group.

Suppose you want to boot the c0t0d0 with 2.6 and c0t2d0 with 2.8,
just store c0t0d0 on the volboot file of c0t0d0 with "vxdctl add disk
c0t0d0", the
same for c0t2d0.

I've never tried this, but it sounds like that might work.

---
Sebastien DAUBIGNE
sebastien.daubigne at sema.fr <mailto:sebastien.daubigne at sema.fr>  - (+33)
(0)5.57.26.56.36
Sema Global Services - AFM/DW/Pessac

	-----Message d'origine-----
	De:	Todd Stansell [SMTP:todd at stansell.org]
	Date:	vendredi 28 dicembre 2001 03:02
	@:	Stephen Hickey
	Cc:	veritas-vx at mailman.eng.auburn.edu
	Objet:	Re: [Veritas-vx] Booting different Solaris versions with
Veritas rootdg's

	We ran into this problem a few years back.  It has to do with the
fact
	that when VxVM initializes, it looks at the timestamp for all of the
	rootdgs and attempts to start the one that's been modified most
	recently, as opposed to starting the one that you're bootstrapping
	from.  This was brought up at VERITAS Vision 2000 with the VxVM
	engineers, and they said that it would be fixed in probably VxVM 3.3
	(or was that 3.2?), but not to hold them to it...

	Suppose you are booted into 2.6, then the rootdg associated with 2.6
is
	going to be updated when it starts (I think it does a flush at some
	point to make sure all of the configuration copies are consistent).
	Then, when you reboot from the disk that will boot you into 8, the
most
	recently updated rootdg is 2.6, not 8, and so it dies in the middle
of
	the boot process when trying to start 8.

	We ended up getting around this problem by writing a script that
would
	either:

	1) flush the current rootdg (if you wanted to boot from 2.6 again -
	   which was only necessary if we were fiddling with the other
rootdgs)

		# vxdg flush rootdg

	2) update the correct rootdg so it's the most recent.

	        # vxdg -Ct -n tempdg import ${DGID} 2>&1 | grep -v
renumbered
	        # vxdg -h `hostname` deport tempdg

	   where ${DGID} is the disk group id of the rootdg for the OS
you're
	   going to boot into next.

	I determined which rootdg was most recently updated by doing the
following:

	# latestid=`vxdisk list \`vxdisk -o alldgs list | awk
'/rootdg/{print $1}'\` | \
	    nawk ' BEGIN        { time=0; latestid="" }
	           /^group/     { id=substr($NF,4) }
	           /^update/    { a=substr($2,6); if (a > time) { time=a;
latestid=id } }
	           END          { print latestid }'`

	We also updated the eeprom to set the boot device to the correct
boot
	disk.  However, the script is very much a hack, since we had to
store
	the boot devices in the script itself, so it wasn't very useful on
more
	than one system.

	Anyway, hope this helps answer some questions without generating too
	many new ones :)

	Todd

	On Mon, Dec 24, 2001 at 02:41:38PM +0000, Stephen Hickey wrote:
	>
	> Hello All,
	>
	> I'll  try to keep this brief. We need to boot different versions
of Solaris
	> (2.6  and  8) from seperate internal disk. Normally, no problem
but we also
	> use  Veritas Volume Manager and, obviously, have the boots disks
in rootdg.
	> I am able to boot from one of the disks (Sol 2.6) but if I try to
boot from
	> the  other disk (Sol 8) then I get an error message along the
lines of "...
	> found  roodg,  but  disk group ID is not the one expected ..." and
the boot
	> fails!
	>
	> Any ideas?
	>
	> Steve.
	_______________________________________________
	Veritas-vx maillist  -  Veritas-vx at mailman.eng.auburn.edu
	http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx



More information about the SunHELP mailing list