The system is configured to boot from a root file system defined on a volume, but there is no root volume listed in the configuration of the boot disk group.

The following are possible causes of this error:


• The /etc/system file was erroneously updated to indicate that the root device is /pseudo/vxio@0:0. This can happen only as a result of direct manipulation by the administrator.
  
  Boot the system on a CD-ROM or networking-mounted root file system, directly mount the disk partition of the root file system, and remove the following lines from /etc/system:
  
  rootdev:/pseudo/vxio@0:0 set vxio:vol_rootdev_is_volume=1
  
  
• The system somehow has a duplicate boot disk group, one of which contains a root file system volume and one of which does not, and vxconfigd somehow chose the wrong one. Since vxconfigd chooses the more recently accessed version of the boot disk group, this error can happen if the system clock was updated incorrectly at some point (reversing the apparent access order of the two disk groups). This can also happen if some disk group was deported and assigned the same name as the boot disk group with locks given to this host.
  
  Either boot the system with all drives in the offending version of the boot disk group turned off, or import and rename the offending boot disk group from another host.
  
  See the vxdg(1M) manual page.
  
  If you turn off the drives, run the following command after booting:
  
  # vxdg flush bootdg
  
  This updates time stamps on the imported version of the specified boot disk group, bootdg, which should make the correct version appear to be the more recently accessed. If this does not correct the problem, contact Veritas Technical Support.
  
  

The system is configured to boot from a root file system defined on a volume, but there is no root volume listed in the configuration of the boot disk group.

A possible cause of this error is that the system somehow has a duplicate boot disk group, one of which contains a root file system volume and one of which does not, and vxconfigd somehow chose the wrong one. Since vxconfigd chooses the more recently accessed version of the boot disk group, this error can happen if the system clock was updated incorrectly at some point (causing the apparent access order of the two disk groups to be reversed). This can also happen if some disk group was deported and assigned the same name as the boot disk group with locks given to this host.

Either boot with all drives in the offending version of the boot disk group turned off, or import and rename the offending boot disk group from another host.

See the vxdg(1M) manual page.

In you turn off drives, run the following command after booting:

# vxdg flush bootdg

This updates time stamps on the imported version of the specified boot disk group, bootdg, which should make the correct version appear to be the more recently accessed. If this does not correct the problem, contact Veritas Technical Support.