Documentation, Support, and Training
Evaluating Product Compatibility
Form-Factor Physical Characteristics
Warranty and Technical Support
System Requirements and Options
Installing Optional Components
Preparing to Install the Blade Server
Power and Thermal Distribution
Required Cooling and Blade Impedance Curve
Local Network IP Addresses and Host Names
Connect the External I/O Cables
Connect Cables to a System Console Running the Oracle Solaris OS
Connect Cables to a System Console Not Running Oracle Solaris OS
Insert and Latch the Blade Server
Software and Firmware Upgrades
Software and Firmware Upgrades
Creating a Boot Disk Server and Adding Clients
Create a Boot Server for Diskless Clients
Compact Flash Formatting for the Oracle Solaris OS
Multiplex Configuration of Zones 2 and 3
Advanced Rear Transition Module Connectors (Zone 3)
Locate Base MAC Address on Blade Server
Configuring and Using Serial Over LAN
Shut Down OS and Deactivate the Blade Server
Power Off and Remove the Blade Server
For documentation on firmware and blade server management, refer to the Oracle Solaris OS and Oracle Solaris system administration documentation. Two of the Oracle Solaris programs commonly used for firmware and blade server management are described in the following sections.
The Oracle Solaris OS installed operates at different run levels. For a full description of run levels, refer to the Oracle Solaris system administration documentation.
Most of the time, the OS operates at run level 2 or run level 3, which are multiuser states with access to full system and network resources. Occasionally, you might operate the system at run level 1, which is a single-user administrative state. However, the lowest operational state is run level 0.
When the OS is at run level 0, the ok prompt appears. This prompt indicates that the OpenBoot firmware is in control of the system.
There are a number of scenarios under which OpenBoot firmware control can occur.
By default, before the operating system is installed, the system comes up under OpenBoot firmware control.
When the auto-boot? OpenBoot configuration variable is set to false, the system boots to the ok prompt.
When the operating system is halted, the system transitions to run level 0 in an orderly way.
When the operating system crashes, the system reverts to OpenBoot firmware control.
During the boot process, when there is a serious hardware problem that prevents the operating system from running, the system reverts to OpenBoot firmware control.
When a serious hardware problem develops while the system is running, the operating system transitions smoothly to run level 0.
When the OS is deliberately placed under the OpenBoot firmware control in order to execute firmware-based commands.
Note - For this blade server, a user modifiable net speed/mode from the OpenBoot ok prompt is not allowed. The Base interface link parameters cannot be modified, and only the default link parameters with auto-negotiation are supported.
For information about getting to the ok prompt, auto-boot options, and OpenBoot commands, refer to the Oracle Solaris system administration documentation.
POST is a firmware program that helps determine whether a portion of the system has failed. POST verifies the core functionality of the system, including the CPU modules, motherboard, memory, and some on-board I/O devices. The software then generates messages that can be useful in determining the nature of a hardware failure. POST can run even if the system is unable to boot.
If POST detects a faulty component, it is disabled automatically, preventing faulty hardware from potentially harming any software. If the system is capable of running without the disabled component, the system boots when POST is complete. For example, if one of the processor cores is deemed faulty by POST, the core is disabled, and the system boots and runs using the remaining cores.
POST diagnostic and error message reports are displayed on a console.