Ignite-UX (IUX) Document for Frequently Asked Questions (FAQ) (762793-001, March 2014) (Edition: 3)

ERROR: Disk group dg02: cannot create:
Disk group exists and is imported
ERROR: Command "/sbin/vxdg init dg02 dg0201=c17t12d0
dg0202=c17t13d0"failed.
The configuration process has incurred an error, would you
like to push a shell for debugging purposes? (y/[n]):
If the affected disk group contains any important volume like /usr, /opt, or /var, this installation
is unlikely to succeed as those volumes are required to boot and bring a system up. If the volumes
are not essential, then it may be possible to ignore all the errors and the system may continue to
boot. There may be additional VxVM errors beyond this initial one:
• To continue and ignore the error, answer y, and at the shell prompt, enter exit 2. Then
press Return.
Or
• To exit the installation, enter n. The system reboots, and then you must reinstall avoiding the
use of duplicate disk group names.
One potential workaround for this problem is to set the control parameter clean_all_disks to
true in *INSTALLFS (For more information about this keyword, see instl_adm(4)). However, this
is not recommended in most instances and extreme caution is required because when this variable
is set to true, all the disks found on the system are cleaned, which might not be intended. Data is
lost on all disks on the system when this variable is set, even if the disks are not explicitly selected
for the installation. In a SAN environment or MC/ServiceGuard cluster, the system you are installing
may be able to detect disks currently used by other systems. Setting clean_all_disks to true
removes the data from them as well, which is not an intended situation. However, this cleans the
disk group data from the other disks on the system, thus eradicating the duplicate disk group names.
NOTE: LVM has the similar problem, but it would be observed when the duplicate group is
imported back via vgimport. In VxVM, the problem is detected at volume group creation time.
VxVM identifies all the disks on the system, and not just those selected for use in the current
installation.
Is SecurePath (previously known as AutoPath) supported by Ignite-UX during installation
or recovery?
It depends on what SecurePath is controlling. Ignite-UX does not support active/passive EVA GL
(EVA3000/EVA5000) disk arrays because of multiple known issues. For more information about
potential issues you might encounter, see the latest version of the Ignite-UX Release Notes (and
search for EVA).
These issues do not affect active/active EVA GL or any EVA XL disk arrays. These disk arrays are
fully supported for use with Ignite-UX.
Why is install.log so difficult to read?
The installation messages that are logged into install.log are obtained by Ignite-UX from
multiple sources including the standard output (stdout) and standard error (stderr) of Software
Distributor and the contents of swagent.log. It is not possible to control how these messages are
logged into install.log, thus the file can be confusing.
If you want to verify the installation of a product, HP recommends that you examine the
swagent.log file directly, rather than the Ignite-UX install.log file.
Frequently asked questions 13