Update Release Summary
Software update ak-2008.11.20.2.0 is applicable to all Sun Storage Series 7000 platforms. This update fixes problems with disk hotplug and cluster restart and rejoin. Customers are strongly encouraged to upgrade their 7110, 7210, and 7410 systems. This update also contains fixes delivered the 1.0.3 release.
To update your system, navigate to the Maintenance/System view and click on the '+' to upload this file.
Supported Platforms
Security Fix
Not Applicable
Issues Addressed
| CR | Synopsis |
|---|---|
| 6803822 | Reboot after replacement of system disk in a ZFS mirror drops to grub> prompt |
| 6803738 | _getgroupsbymember is very slow in nss_ak |
| 6620200 | mpt should protect access to doorbell |
| 6766975 | Panic when sas cable disconnected between pcie0 and sim 0 out, IOC restart after hardware changes |
| 6786612 | mpt warnings when scsi hba installed |
| 6795934 | mpt needs extra debugging capabilities |
| 6800265 | mpt should disable tracing during panic |
| 6803061 | cv_destroy in wrong place in mpt |
| 6785217 | AKD Panic - Cluster peer fails to rejoin cluster - "unrecoverable protocol error". |
| 6803030 | User and group validation are confused by ephemeral UID/GIDs |
Known Issues
| Release Note | RN001 |
|---|---|
| Title | IP Multipath Interface Failover When ICMP Probes are Lost |
| Platforms | All |
| Related Bug IDs | 6730274 |
IP Multipath groups can be configured to permit fail-over of IP addresses from one IP interface to another when either (a) a physical network device transitions to link-down, or (b) when an external network switch or path is no longer working. In the first software release, both of these failure mechanisms are always configured for IPMP groups. External path failure detection is performed by sending ICMP probes to neighboring addresses or gateway addresses. As a result, if network load and the network environment is such that ICMP probes are dropped, this may trigger an IPMP group fail-over even when the network is still servicing some traffic. To work-around this problem if it is a fundamental behavior of your network environment and load, go to Configuration/Services/IPMP and simply tune the ICMP probe error interval to an extremely high value such as 36000000 (ten hours).
| Release Note | RN002 |
|---|---|
| Title | Network Datalink Modifications Do Not Rename Routes |
| Platforms | All |
| Related Bug IDs | 6715567 |
The Configuration/Network view permits a wide variety of networking configuration changes on the Sun Storage system. One such change is taking an existing network interface and associating it with a different network datalink, effectively moving the interface's IP addresses to a different physical link (or links, in the case of an aggregation). In this scenario, the network routes associated with the original interface are automatically deleted, and must be re-added by the administrator to the new interface. In some situations this may imply loss of a path to particular hosts until those routes are restored.
| Release Note | RN003 |
|---|---|
| Title | Network Reconfigurations Involving the Active Administrative Interface |
| Platforms | All |
| Related Bug IDs | - |
The Configuration/Network view permits a wide variety of networking configuration changes on the Sun Storage system. One such change is modifying or deleting the active administrative interface over which the administrator is connected to the web browser or command-line interface itself, which may also be providing the default route for the system. The appliance software attempts to detect such modifications and warn the administrator first. If such a reconfiguration is confirmed or not detected in advance, the administrator will lose contact with the appliance during the network reconfiguration. The network reconfiguration will complete, but if contact cannot be restored with the appliance (by reloading the web address or reconnecting using ssh) due to an error in the configuration applied by the administrator or the loss of the default route, the administrator should log in using the service processor console and correct the configuration using the command-line.
| Release Note | RN004 |
|---|---|
| Title | J4400 Emits Audible Alarm When a Drive is Hot-Unplugged |
| Platforms | 7410 |
| Related Bug IDs | 6725548 |
In the current version of J4400 Array firmware, used in the disk enclosures for the Sun Storage 7410, the J4400 emits an audible alarm when a disk drive is hot-unplugged. The alarm warns the operator that a drive has been removed, and the alarm is silenced when the drive is replaced, either by the original drive or by a new replacement. In some operator scenarios, it may be preferable to not emit such an alarm, particularly if a spare drive is not immediately available. The operator can manually silence the alarm by depressing a button on the J4400 front panel. Future versions of the J4400 firmware and appliance software will disable this behavior and/or permit it to be configured by the administrator.
| Release Note | RN005 |
|---|---|
| Title | Shares Should be Specified for NDMP Backup |
| Platforms | All |
| Related Bug IDs | 6758825 |
The Sun Storage products permit administrators to manage collections of shares and LUNs, grouped together into named projectsthat have common settings. NDMP backup applications operate on mounted filesystems and do not intrinsically understand Sun ZFS metadata and the relationship between projects and shares. In the current release of the Sun Storage 7x10 products, NDMP backup applications should be configured to backup individual shares of interest, and should not be directed to backup or restore the base mountpoint associated with an entire project. These settings will insure that individual shares are backed up and restored with all of their associated independent metadata.
| Release Note | RN006 |
|---|---|
| Title | Restart and Rejoin Behavior in a Cluster |
| Platforms | 7410 |
| Related Bug IDs | 6768696, 6771969, 6769622 |
The Sun Storage 7410 can be configured as an active-active or active-passive cluster with two 7410 systems connected together by means of a cluster interconnect and a shared set of storage arrays. Refer to the product documentation for a complete description of the clustering functionality and setup procedures. If a cluster node encounters a software or firmware defect that results in a system software failure, that cluster node will reboot and save postmortem debugging information, and then attempt to rejoin the cluster. If a cluster node encounters a software or firmware defect that causes the system to not execute i/o or management traffic under certain conditions, it may not automatically restart: administrators can use the lights-out management service processor, or an equivalent IPMI command over the network, to manually force the restart and rejoin of that node. During such a restart, the other node in the cluster will automatically detect the restart and take-over for the failing node appropriately. When a cluster node is restarting, it will automatically attempt to rejoin the cluster and will execute the rejoin process indefinitely, showing its progress on the serial console (accessible from the service processor). If the node encounters a software or firmware defect such that the rejoin process is not able to make progress, that node can be safely rebooted at any time by an administrator using the service processor or IPMI, and it will begin the rejoin process again once the node reboots.