Veritas InfoScale™ 7.0 Release Notes - Solaris
- About this document
- Important release information
- About the Veritas InfoScale product suite
- Licensing Veritas InfoScale
- About Symantec Operations Readiness Tools
- Changes introduced in 7.0
- Licensing changes for InfoScale 7.0
- Changes related to installation and upgrade
- System requirements
- Fixed Issues
- Known Issues
- Issues related to installation and upgrade
- Storage Foundation known issues
- Dynamic Multi-Pathing known issues
- Veritas Volume Manager known issues
- Virtualization known issues
- Veritas File System known issues
- Replication known issues
- Cluster Server known issues
- Operational issues for VCS
- Issues related to the VCS engine
- Issues related to the bundled agents
- Issues related to the VCS database agents
- Issues related to the agent framework
- Issues related to Intelligent Monitoring Framework (IMF)
- Issues related to global clusters
- Issues related to the Cluster Manager (Java Console)
- VCS Cluster Configuration wizard issues
- LLT known issues
- I/O fencing known issues
- GAB known issues
- Operational issues for VCS
- Storage Foundation and High Availability known issues
- Storage Foundation Cluster File System High Availability known issues
- Storage Foundation for Oracle RAC known issues
- Oracle RAC known issues
- Storage Foundation Oracle RAC issues
- Storage Foundation for Databases (SFDB) tools known issues
- Storage Foundation for Sybase ASE CE known issues
- Issues related to installation and upgrade
- Software Limitations
- Storage Foundation software limitations
- Dynamic Multi-Pathing software limitations
- Veritas Volume Manager software limitations
- Veritas File System software limitations
- SmartIO software limitations
- Dynamic Multi-Pathing software limitations
- Replication software limitations
- Cluster Server software limitations
- Limitations related to bundled agents
- Limitations related to VCS engine
- Cluster configuration wizard limitations
- Limitations related to the VCS database agents
- Cluster Manager (Java console) limitations
- Limitations related to I/O fencing
- Limitations related to bundled agents
- Storage Foundation Cluster File System High Availability software limitations
- Storage Foundation for Oracle RAC software limitations
- Storage Foundation for Databases (SFDB) tools software limitations
- Storage Foundation for Sybase ASE CE software limitations
- Storage Foundation software limitations
- Documentation
Boot fails after installing or removing SFHA packages from a Solaris 9 system to a remote Solaris 10 system (1747640)
The following issue occurs if you install or remove a Storage Foundation package or patch from a Sparc Solaris 9 system to a remote Solaris 10 system, using the -R rootpath option of the pkgadd, patchadd, pkgrm or patchrm commands.
Generally, when you install or remove a SFHA package on a Solaris 10 system, the package scripts update the boot archive. However if the local system is Solaris 9 and the remote system is Solaris 10, the scripts fail to update the boot archive on the Solaris 10 system.
Note:
The boot archive is synchronized correctly when you upgrade SFHA using Solaris Live Upgrade.
Workaround: The workaround is to manually clear the boot archive when you boot the alternate. The SUN boot process detects that the boot archive is out sync and displays instructions for how to correct the situation.
For example:
WARNING: The following files in / differ from the boot archive: stale //kernel/drv/sparcv9/vxportal stale //kernel/drv/vxportal.conf stale //kernel/fs/sparcv9/vxfs ... new /kernel/drv/vxlo.SunOS_5.10 new /kernel/drv/vxlo.conf changed /kernel/drv/vxspec.SunOS_5.9 changed /kernel/drv/vxspec.conf The recommended action is to reboot to the failsafe archive to correct the above inconsistency. To accomplish this, on a GRUB-based platform, reboot and select the "Solaris failsafe" option from the boot menu. On an OBP-based platform, reboot then type "boot -F failsafe". Then follow the prompts to update the boot archive. Alternately, to continue booting at your own risk, you may clear the service by running: "svcadm clear system/boot-archive"