Arctera

Uninstallation of packages during rolling upgrade fails if kernel packages are present in non-global zones under VCS control (4054919)

December 9, 2025

Contributed by:

As part of the InfoScale rolling upgrade process on Solaris, a few kernel packages are uninstalled before their newer versions are installed. If a non-global zone is under VCS control during the rolling upgrade, that zone fails over to the other system. Consequently, the state of the zone is changed to configured, and therefore, the uninstallation of the related kernel packages fails.

Before you perform a rolling upgrade on Solaris, check whether any non-global zones are under VCS control and whether any related kernel packages are installed. The InfoScale product installer does not handle the upgrade of such non-global zones. Consequently, the non-global zone resources that are under VCS control go into the FAULTED state.

Workaround: Perform the following steps to bring the service group of such a non-global zone online and test its failover.

Clear the fault on the service group.

# /opt/VRTS/bin/hagrp -clear <zone_service_group_name> -any
Take the zone resource offline on the current cluster node.

# /opt/VRTS/bin/hares -offline <zone_resource_name> -sys <system_name>
Check whether the zone is in the configured state.
Set the publisher value to Veritas for the packages and the patches that have been installed with the rolling upgrade.
Attach the zone.

# zoneadm -z <zone_name> attach -u

When the zone is successfully attached, it transitions to the installed state.
Check whether all the packages in the zone are upgraded to the latest version.

Note that kernel packages like VRTSodm and VRTSvxfs may not be upgraded, because they need to be handled differently.
To upgrade the VRTSodm and the VRTSvxfs packages within the zone, uninstall and then install them again.

# pkg -R <zone_path>/root uninstall VRTSodm VRTSvxfs

# pkg -R <zone_path>/root install --accept --no-backup-be VRTSodm VRTSvxfs
Perform steps through on each cluster node separately.
After all the nodes are updated, bring the zone service group online on any of the cluster nodes.

# /opt/VRTS/bin/hagrp -online <zone_service_group> -sys <system_name>
After the service group comes online, test the failover by switching the group to another node.

# /opt/VRTS/bin/hagrp -switch <zone_service_group> -to <system_name>

The official version of this content is in English. Some of the Cloud Software Group documentation content is machine translated for your convenience only. Cloud Software Group has no control over machine-translated content, which may contain errors, inaccuracies or unsuitable language. No warranty of any kind, either expressed or implied, is made as to the accuracy, reliability, suitability, or correctness of any translations made from the English original into any other language, or that your Cloud Software Group product or service conforms to any machine translated content, and any warranty provided under the applicable end user license agreement or terms of service, or any other agreement with Cloud Software Group, that the product or service conforms with any documentation shall not apply to the extent that such documentation has been machine translated. Cloud Software Group will not be held responsible for any damage or issues that may arise from using machine-translated content.

Was this helpful

Uninstallation of packages during rolling upgrade fails if kernel packages are present in non-global zones under VCS control (4054919)

December 9, 2025

Contributed by:

December 9, 2025

Contributed by:

Uninstallation of packages during rolling upgrade fails if kernel packages are present in non-global zones under VCS control (4054919)

In this article