We just got a new Sun V245 in and the encapsulation process for Veritas 4.1 seems to be broken -- for some reason it's not putting the following lines into /etc/system:

	rootdev:/pseudo/vxio@0:0
	set vxio:vol_rootdev_is_volume=1

This causes a failure on reboot like this:

ERROR: svc:/system/filesystem/usr:default failed to mount / (see 'svcs -x' for details)

If we try to mount root by hand from single user mode we get this:

	# mount -m -F ufs -o remount,nologging / 
	mount: /dev/vx/dsk/bootdg/rootvol is not this fstype
	# fstyp /dev/vx/dsk/bootdg/rootvol
	ufs 

Which is a little strange...

If we boot the system to the network, mount the boot drives and add the missing lines to /etc/system, the system boots up without issues, fully encapsulated.

We don't see this problem on older systems. I have a hunch that this is related to the SAS drives in this system and some Veritas script erroring before it can put these lines in place, but I have nothing to back that up.

Anyone else seeing this?

 

 

Hello Michael,
after having the same Problem (no boot after encapsulating rootdisk on V245) I found your message.
Same behavior as you describe.

I think, the error occurs in the vxroot command. See the lines from boot below.
VxVM vxroot INFO V-5-2-290 Saving original configuration...
16 blocks
/usr/lib/vxvm/bin/vxroot: test: argument expected
VxVM vxvm-reconfig ERROR V-5-2-337 The encapsulation of the Boot Disk failed.
VxVM vxvm-reconfig NOTICE V-5-2-393 The system will now be rebooted.

Greetings,
Stefan

 

 

Well, we finally figured out what the problem is/was from a hint in the file /var/svc/log/system-vxvm-vxvm-reconfig:default.log where it said "vxroot: test: argument expected"

That lead us to the script /usr/lib/vxvm/bin/vxroot and line 138 where there is a basic scripting error:

	if [ $? -eq 0 -a -n $bus_drivers ] ;

The bus_drivers var should be quoted.

	if [ $? -eq 0 -a -n "$bus_drivers" ] ;

Changing this fixes the problem.

The frustrating thing is that this is fixed in version 5 (it was apparently introduced in 3.1.1) -- why didn't they back port this fix to 4.1 when they found the error?

Anyway, I hope this helps out some folks.

 

 

Personally I tend to avoid using vxvm for root.

We use svm for root and vxvm for san volumes.

Its much easier to recover from root mirror issues by unmirroring and booting of the single disk with svm than it is for vxvm....

 

 

Anyway, it is not necesary to boot from network to solve the problem. To make the root disk writable in order to fix /etc/system, just execute:

# mount -o remount,rw /dev/dsk/cxtxdxsx /
(where cxtxdxsx is your root disk)

Of course, to use "vi" it would be handy to mount /var as well.

 

 

Personally I'd just use the hardware raid controller that is built into the V245 and mirror the system disk that way. INFODOC 87435.

 

 

Thanks for this post....I had the same issue today. My experience with V245 has not been pleasant. For instance, I ran into a problem when jumpstarting the V245 would panic. Had to patch the miniroot on the jumpstart server. That took some time figure out. Anyway great post. Saved me tons of time.

 

 

This helped us a lot thamks for posting solution for this issue