![Oracle DE2-24 Customer Service Manual Download Page 308](http://html1.mh-extra.com/html/oracle/de2-24/de2-24_customer-service-manual_1646220308.webp)
Working with Firmware Upgrades
■
There are updates in the Failed state.
■
Updates remain in the Pending state (or in limbo between the Pending and In Progress
states) for an extended period of time (more than half an hour), without the number of
remaining updates decreasing.
The following condition does not indicate a problem:
■
There are multiple chassis being updated, we are making progress (the number of remaining
updates decreases), and some of the chassis transiently appear pending with a status
indicating that some disk has only one path. This is also expected, since when we update
a chassis, we may reset one of its expanders. Resetting an expander causes some disks to
temporarily have only one path, and as a result, upgrades to other chassis are held back until
it is safe to do so again non-disruptively.
Note that currently the Firmware Updates dialog does not automatically refresh, so you would
have to close it and re-open it to get an updated view.
Applying hardware updates is always done in a completely safe manner. This means that
the system may be in a state where hardware updates cannot be applied. This is particularly
important in the context of clustered configurations. During takeover and failback operations,
any in-progress firmware upgrade is completed; pending firmware upgrades are suspended
until the takeover or failback has completed, at which time the restrictions described below are
reevaluated in the context of the new cluster state and, if possible, firmware upgrades resume.
Caution -
Unless absolutely necessary, takeover and failback operations should not be
performed while firmware upgrades are in progress.
The rolling upgrade procedure documented later meets all of these best practices and addresses
the per-device-class restrictions described later. It should always be followed when performing
upgrades in a clustered environment. In both clustered and standalone environments, these
criteria are also reevaluated upon any reboot or diagnostic system software restart, which may
cause previously suspended or incomplete firmware upgrades to resume.
■
Components internal to the storage controller (such as HBAs and network devices) other
than disks and certain SAS devices are generally upgraded automatically during boot; these
upgrades are not visible and will have completed by the time the management interfaces
become available.
■
Upgrading disk or flash device firmware requires that the device be taken offline during
the process. If there is insufficient redundancy in the containing storage pool to allow this
operation, the firmware upgrade will not complete and may appear "stalled." Disks and
flash devices that are part of a storage pool which is currently in use by the cluster peer, if
any, are not upgraded.
■
Upgrading the firmware in a disk shelf requires that both back-end storage paths be active
to all disks within all enclosures, and for storage to be configured on all shelves to be
308
Oracle ZFS Storage Appliance Customer Service Manual • February 2016