T5-4 - Main Module Motherboard Replacement Process When Veritas Foundation Suite Is Installed on Control Domains
(Doc ID 2283936.1)
Last updated on JUNE 14, 2019
Applies to:SPARC T5-4 - Version All Versions and later
Solaris x64/x86 Operating System - Version 10 3/05 and later
Solaris Operating System - Version 10 3/05 and later
Information in this document applies to any platform.
How to avoid extended boot delay
The replacement of the MM on T5-4 platform is described in the following doc id.
How to Replace a SPARC T5-4 or T5-8 Server Main Module Motherboard:ATR:1528030.1:2 (Doc ID 1528030.1)
As part of the motherboard replacement operation, the platform needs to be set to 'factory default' mode, which can change the way physical access to attached storage is or is not restricted.
When the system is booted after the 'factory default' mode is set, vxvm/vxdmp can be presented with an enlarged kernel device tree, without matching /dev/[r]dsk paths for all disks now exposed in the kernel device tree. This delays the boot time discovery and configuration process that vxdmp needs to complete before the Solaris image fully completes the boot process.
In particular, vxvm/vxdmp has to deal with a configuration that has now changed from the logical domain configuration upon which it was initially installed and configured, and now has to resolve
An inquiry probe to all devices is successful ( through the Solaris kernel ) but not all of these devices are fully configured and available ( /dev/[r]dsk paths are missing for the additional devices now 'exposed' by 'factory default' mode ).
Those devices without a /dev/[r]dsk path are not fully accessible and return IO errors. As part of its error handling mechanism, vxvm/vxdmp issues an inquiry probe to determine if the device is
ready, and to determine the status of the path to the device. As this probe is successful, vxvm/vxdmp concludes that the path is available, and the device is ready to be accessed. Therefore, vxvm/vxdmp continues to (unsuccessfully ) access this device, including retries, until the timeout limit is reached.
The system does eventually complete a successful boot, but clearly the extended boot delay is undesirable.
Note. Following the replacement of the service processor or motherboard or main module in a SPARC CMT server, the saved LDoms config will get lost.
As a result, the issue described in this doc will occur if Veritas is installed.
For your reference, please have a look at:
How to Replace the Motherboard or Service Processor in a Logical Domain (LDom) Environment (Doc ID 1019720.1)
Depending on platform type the LDom configuration is stored within the Service Processor or Motherboard/Main Module -
when these components are replaced the LDom configuration will be lost;
[T1000, T2000, Netra T2000]
Stored within the /persist filesystem residing on the Service Processor
[T5x20, T5x40, Sun Blade T63x0, Netra T5xx0]
Stored within Host Data Flash embedded on the Service Processor
[T3-1, T3-2, T3-1B, Netra T3-1, T4-1, T4-2, T4-1B, Netra T4-x, T5-2, T5-1B]
Stored within Host data Flash embedded on the System Board
[T3-4, T4-4, T5-4, T5-8 S7-2, S7-2L, T7-1, T7-2, T7-4]
Stored within Host Data Flash embedded on the Main Module (Motherboard).
see also parameters suggested by Veritas
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document
|How to avoid extended boot delay|