Error Message

== Creating PdDv entry == Creating Config_Rules entries == Creating CuDv entry mkdev: 0514-517 The information provided to this configuration command was not adequate to uniquely identify the device. Provide more device information than the following: type = 'vxportal' AND subclass = 'node' AND class = 'vxdrv' mkdev failed == Attempting cleanup after errors == Try again
== Creating PdDv entry == Creating Config_Rules entries == Creating CuDv entry mkdev: 0514-517 The information provided to this configuration command was not adequate to uniquely identify the device. Provide more device information than the following: type = 'vxqio' AND subclass = 'node' AND class = 'vxdrv' mkdev failed == Attempting cleanup after errors == Try again
UX:vxfs vxtunefs: ERROR: V-3-20113: Cannot open /dev/vxportal: A file or directory in the path name does not exist.
UX:vxfs vxtunefs: ERROR: V-3-26748: failed to set the specified parameters: A file or directory in the path name does not exist.
UX:vxfs vxtunefs: ERROR: V-3-26721: unable to update value in the file /etc/vx/vxfssystem

This is a known issue with VxFS 6.x. In this instance, when upgrading to 6.2 the upgrade will fail due to an interoperability issue.

During an alternate disk installation (Live Upgrade) and while defining the vxportal0 device for ODM configurations in vxextadm, it is observed that vxportal0 exists. As a result, vxextadm fails and all previous configurations are cleared. During the clean up, the /dev/portal device is removed, resulting in the error message.

The Veritas 6.2.1 software cannot be used during the initial alternate disk upgrade deployment, the base 6.2 software must be installed first.

The base 6.2 Veritas software install needs to be replaced with the modified VRTSvxfs.bff file. 

The code is modified to add a check that validates if vxportal0 and qio0 are defined before they are added to the ODM. However, the issue still occurs during alternate disk upgrade, even when including this patch in the filesets to be applied.

Veritas Engineering has produced a modified base fileset for VxFS 6.2 which corrects this issue. Please contact Veritas Technical Support to obtain the modified VRTSvxfs.bff file.
 

The special VRTSvxfs.bff file needs to manually replace the existing 6.2 VRTSvxfs.bff
 
 
Below are the steps to do alt_disk_install:
 
1. Install and configure 6.1.1 GA (assuming this is currently installed in cust. env) on the current rootvg.

2. Create shared diskgroup incase of cfs and cluster mount the fs.

3. Create some files and run some I/Os on the fs.

4. Identify the free disk for alternate rootvg (use lspv command).

5. Identify all the 6.2 packages to upgrade.

6. Copy these packages to any directory, say /62pkgs

7. cd to /62pkgs and replace the base 6.2 VRTSvxfs.bff pkg with the special VRTSvxfs.bff pkg.

8. Run this command: /usr/sbin/alt_disk_copy -d -w all -l /62pkgs -I acNgXY -P all

9. Wait till all the filesets are applied and boot list is changed to the alternate disk (you can check that by running: bootlist -m normal -o)

10. reboot the server and see if rootvg now has the alternate disk (use command lspv) and also verify the installed pkgs.
 
Note: In the step 7 if we do not replace the VRTSvxfs.bff pkg it gives error while applying the VRTSvxfs fileset.

 

 

The base 6.2.1 does not encounter the issue for nw installations not requiring the alternate disk upgrade functionality.

The only other way to avoid this issue is to avoid the AIX alternate disk upgrade, and install 6.2.1 + patches in the traditional way. Once 6.2.1 + patches are installed, the AIX feature can then be used.
 

When using the alternate disk upgrade method for AIX to upgrade your environment to Storage Foundation 6.x, an error is logged during the Veritas File System (VxFS) installation.

This error leads to the /dev/vxportal device being deleted. The VxFS file systems can no longer be mounted until the system is rebooted.

ETrack: 3451725