| Sun Fire Entry-Level Midrange Systems Firmware 5.18.0 Release Notes |     |
| Sun Fire Entry-Level Midrange Systems Firmware 5.18.0 Release Notes | |
|
Sun Fire Entry-Level Midrange Systems Firmware 5.18.0 Release Notes |
This document provides information on new and revised features, as well as late-breaking news, for firmware release 5.18.0 on Sun Fire E2900 Sun Fire V1280, and Netra 1280 systems.
This document contains the following topics:
This section provides a brief description of the new features in 5.18.0 for Sun Fire entry-level midrange systems.
The Secure Shell protocol, which provides secure remote access to the system controller, is now available as an alternative to the Telnet protocol on Sun Fire entry-level midrange systems. SSH uses encryption to protect data flowing between the host and client, and also authentication mechanisms to identify both hosts and clients.
The system controller (SC) provides SSHv2 server capability. For further information on SSH and how to configure secure connections, refer to Chapter 8, "Security Guidelines," in the Sun Fire Entry-Level Midrange System Administration Manual.
The following SSH support commands are not available on an entry-level midrange system equipped with an SC V1:
If you choose to use the default without creating DSA host keys, you will see the following message when the SSH server is enabled:
If you try to use any of the above features, an error message is generated. For example, running the command
generates the following messages:
The Capacity on Demand (COD) option provides additional processing resources that you pay for when you use them. Through the COD option, you receive and install unlicensed CPU/Memory boards. These boards, which are identified as COD CPU/Memory boards, contain four CPUs. However, you do not have the right to use the CPUs on COD CPU/Memory boards until you also purchase the COD right-to-use (RTU) licenses for them. The purchase of a COD RTU license entitles you to receive a license key, which enables the appropriate number of COD processors.
Your Sun Fire entry-level midrange system can have any combination of active CPU/Memory boards and COD CPU/Memory boards, up to the maximum capacity allowed for the system. You must have at least one active CPU in your system.
For details on getting started with COD, review the Capacity on Demand chapter in the Sun Fire Entry-Level Midrange System Administration Manual (part number 817-7812-10). Contact your Sun sales representative or authorized Sun reseller to purchase COD CPU/Memory boards and the appropriate number of COD RTU licenses. After the COD CPU/Memory boards are installed, refer to the Capacity on Demand chapter and also the Sun Fire Entry-Level Midrange System Controller Command Reference Manual (part number 817-7811-10) for information on using certain system controller commands to allocate COD RTU licenses, activate COD CPUs, and monitor the COD CPUs used.
The following SC commands were changed in 5.18.0
The following command descriptions were modified in the entry-level command reference manual:
5.18.0 firmware modifies the behavior of the Open Boot PROM when booting off of the network using the DHCP protocol.
During the network boot process, clients use TFTP to download an initial boot binary file (such as inetboot) from a TFTP boot server specified by the DHCP server. If the DHCP server does not tell the client the name of the file to be downloaded, the Open Boot PROM uses a default file name for the TFTP request. In previous firmware releases the default boot file name was the client's IP address expressed as a string of eight hexadecimal characters (for example, a client whose IP address was 192.168.100.1 would request a file named C0A86401). While this behavior is correct for non-DHCP network boots, it is incorrect for network booting with DHCP.
Starting in this release, the default boot file name used by the Open Boot PROM is constructed from the client's platform type. Unless the DHCP server specifies a different boot file name, midrange platforms request a file named SUNW.Sun-Fire while entry-level midrange platforms request a file named SUNW.Netra-T12. This behavior is consistent with the net boot server setup tools distributed with Solaris software.
With this change, you might (depending upon your network boot configurations) see net boot errors after installing the new firmware. Specifically, if the requested boot file does not exist on the TFTP boot server, the Open Boot PROM issues the following message and fails to boot the OS:
ERROR: get_tftp_file: TFTP error 2: Access violation
Workarounds: This situation can be corrected in several ways, including (but not limited to):
The DHCP network boot process supports configurations in which the DHCP server and the TFTP boot server are different machines. If the DHCP server and other network components are configured correctly, the DHCP and TFTP servers can exist on different IP subnets. However, the Open Boot PROM firmware in previous releases assumes that the DHCP server and the TFTP server are the same machine even if the DHCP server indicates otherwise.
Starting with this release, the Open Boot PROM handles configurations correctly in which the DHCP and TFTP servers are not the same machine, including when they are on different subnets. For cross-subnet TFTP configurations, note that the DHCP server must be configured to provide proper Router and Subnet values to the client.
With this change, if your DHCP servers are improperly configured (providing incorrect Router or Subnet values to clients), you might see net boot errors after installing the new firmware. OpenBoot PROM firmware on the client might issue one or both of the following messages in that situation:
ERROR: get_arp_info: Timeout waiting for ARP packet
ERROR: tftp_get_reply: Timeout waiting for TFTP packet
Workaround: To eliminate these error messages, verify that the Router and Subnet values sent to the client by the DHCP server are correct.
The Sun Fire E2900 systems require 5.17.0 firmware or greater and the Solaris 8 2/04 or Solaris 9 4/04 operating environments as the minimum Solaris releases.
Instructions for updating firmware (upgrade and downgrade) are provided in the Sun Fire Entry-Level Midrange System Administration Guide.
Sun Fire E2900 systems and Sun Fire V1280 systems that contain UltraSPARC IV CPU/Memory boards must run firmware version 5.17.0 or greater. Earlier firmware versions do not support the UltraSPARC IV CPU/Memory boards.
Entry-level midrange systems with SC V2s can be downgraded from 5.18.0 to earlier firmware releases, but note that those earlier releases will not support bug fixes made in 5.18.0.
This section describes only those bugs with potentially significant impact. The README file lists all bugs, including those seen only internally at Sun.
If you change the connection type after updating firmware on entry-level midrange systems from 5.17.x or 5.18.x to 5.13.x, then the new connection type (selected in 5.13.x) is not guaranteed once you update firmware back to 5.17.x or 5.18.x. If you subsequently update the firmware to 5.17.x or 5.18.x from 5.13.x, the original connection type that you had in 5.17.x or 5.18.x before the change to 5.13.x will be restored.
Workaround: Set the connection type explicitly (using the setupnetwork command) to ensure system security.
If you update the SC firmware to a version earlier than 5.18.0, leaving RTOS 40 installed, it is possible to change the scapp NTP server configuration--resulting in RTOS 40 listening to one NTP server and scapp listening to different one.
Workaround: When downgrading scapp, unconfigure the NTP server, and reconfigure it after downgrading. This disables NTP operations until you explicitly re-enable them.
If components in an entry-level midrange server are missing or disabled, the FRU ID Info table in Sun Management Center software cannot display the hardware FRU (Field-Replaceable Unit), except for the SSC and BP entries. The remaining entries in the table contain this message: "Reading ..."
The System table's Module Status entry reports FRU ID errors, displaying a critical alarm indicator. The alarm message states: "Data acquisition error" while the software attempts to obtain the Module Status.
Workaround: Use /usr/sbin/prtfru to print out the FRU tree hierarchy and data in a terminal shell.
If you add a new system board when the system is in Standby mode (that is, having used the lom> poweroff command), once the system has booted to the OS
(lom> poweron) prtdiag command output shows incorrect or missing entries for the new board. This problem does not occur when the system has been fully powered off before adding the new board or when the new board has been dynamically reconfigured in a live system.
This problem has been observed only when using 5.13.x firmware on entry-level midrange systems.
In order to get the prtdiag and lom commands to report correctly, reset the system controller after completing the DR operation.
1. Reconfigure the new board dynamically:
a. # cfgadm -c disconnect N0.SBx
b. # cfgadm -c configure N0.SBx
In rare circumstances, the showboards command displays system boards (SB0, SB2., and so forth) as being in the state, PWR: Unk (power status unknown) and Status: failed (suggesting that the boards have all failed diagnostics). This condition is likely to be a reporting error, and does not necessarily mean that there is anything wrong with the boards.
This situation might be more likely to occur after use of the poweroff command.
Workaround: Use the resetsc command to reset the system controller. The showboards command should then show the system boards in the correct state. This reset does not affect the domain state. However, if resetting the SC does not correct the problem, you can power down the entire system and bring it up again (which resets the domain as well).
Use of the prtfru command sometimes results in IO error messages being returned instead of data for many of the Field Replaceable Units (FRUs) in the system. If the Solaris OS waits for the completion of an operation on the System Controller, such as a board test or diagnostic command, uncached FRU information might not be available until that operation completes. The Solaris OS can time out after a few seconds or minutes, resulting in the observed IO error messages. This problem might correct itself when the operation blocking the prtfru command completes. However, depending on the operation, this might take several hours.
If the prtfru command produces IO errors on an entry-level midrange system, re-issue the command after waiting for an hour. If the prtfru command continues to fail, it should be considered a permanent condition which cannot be corrected without rebooting the server. Information about the health of the components in the system might be available in other ways, such as by use of the showboards command.
After a domain panic occurs or when a domain encounters errors, output from a subsequent setkeyswitch or testboard operation will show that the board processors have an Unknown status.
Workaround: Reboot the system controller.
A message indicating that there are dropped console messages is displayed when data is being provided by Solaris software or by the OpenBoot PROM faster than the system controller can write it to the console.
If you run the disablecomponent or setls command to blacklist an I/O card, the card is not disabled at the OpenBOOT Prom (OBP) level.
Workaround: Perform a setkeyswitch off and then a setkeyswitch on operation after disabling the I/O card.
If you are using a wanboot server to boot a Sun Fire midrange system (E6900, E4900, E2900, 6800, 4810, 4800, 3800, and V1280), the wanboot server cannot create the ramdisk and is unable to boo the Sun Fire midrange system.
In certain situations, this error message can occur when running reset or shutdown commands from the domain console shell. The error does not affect the availability of the domain. However, the reset or shutdown commands may take an additional 60 seconds to complete.
If a power failure and ScApp reboot occurs during an add segment operation, one or more SEEPROM segments may become corrupted upon a reboot. However, even though these error messages display, the availability of the domains is not affected.
| Sun Fire Entry-Level Midrange Systems Firmware 5.18.0 Release Notes | 817-7810-10 | |
Copyright © 2004, Sun Microsystems, Inc. All Rights Reserved.