|Skip Navigation Links|
|Exit Print View|
Oracle® ZFS Storage Appliance Customer Service Manual
For ZS3-x, 7x20 Controllers, and DE2-24, Sun Disk Shelves
The system update feature provides customers, developers, and field personnel with the ability to update a system's software after the system is installed. You can be notified when new software updates are available on My Oracle Support (MOS) or you can perform an immediate check for updates, using the BUI or CLI.
You can set up periodic checks for software updates, or you can check for updates at any time. When an updated software package is available, you are directed to download the latest package from MOS. To use the update notification feature, the Phone Home service must be enabled, as described in Phone Home Service in Oracle ZFS Storage Appliance Administration Guide .
An update is available on My Oracle Support version 2013.1.0.1.
zfs-appliance:configuration services scrk> ls ... updatecheck_on = false time_updatecheck = 7d ... zfs-appliance:configuration services scrk> set updatecheck_on=true updatecheck_on = true (uncommitted) zfs-appliance:configuration services scrk> set time_updatecheck=30d time_updatecheck = 30d (uncommitted)
Update available for download
zfs-appliance:maintenance system updates> show Updates: UPDATE DATE STATUS 2013.1.1.5 2014-2-18 08:00 downloadable email@example.com,1-0 2014-1-15 14:38:53 previous firstname.lastname@example.org,1-0 2014-2-1 19:38:55 previous email@example.com,1-0 2014-2-8 08:59:04 current zfs-appliance:maintenance system updates> zfs-appliance:maintenance system updates> select status=downloadable zfs-appliance:maintenance system 2013.1.1.5> show Properties: version = 2013.1.1.5 date = 2014-2-18 08:00 status = downloadable url = https://updates.oracle.com/Orion/Services/download /p18269573_20131_Generic.zip?aru=17312483&patch_file=p18269573_20131_Generic.zip checkdate = 2014-3-4 zfs-appliance:maintenance system 2013.1.1.5>
Software updates are delivered as opaque binary downloads that contain some or all of:
Management and system software.
Firmware for internal components such as HBAs and network devices.
Firmware for disks and flash devices.
Firmware for external storage enclosure components.
The updated release notes describe what is in the update, and the update process automates all of the steps of activating the delivered components. The procedure for updating the system is as follows:
Download the software update "media" from My Oracle Support (MOS) or from another official source. The media is represented by a single compressed file named after the version number, such as: ak-nas-2013-06-05-0-0.0.pkg.gz. You can rename the file if needed, as the true version number is recorded internally within the image. The compressed media packages vary in size, but typically are on the order of several hundred megabytes.
Upload the software update to the appliance, using either the BUI or the CLI. See later for details of this operation.
After you upload the media, it is unpacked and verified. If all verification checks pass, it appears in the list of update images as eligible for installation. Any number of images can be maintained on the appliance, subject to a system disk space quota, without actually applying them. If an update has not yet been applied (i.e., is not running and is not a rollback target), it can be deleted via either the BUI or the CLI. You might want to delete images to free up needed space to download new images.
Verify that the system is in a healthy state prior to applying the update. The details are described in Preconditions.
After the media is unpacked and verified, you can apply the update. During this process, an update health check is performed to verify that the appliance is ready to update. You may be asked to set update options and confirm. For more information on these questions, see the section on deferred updates. If the update is no longer appropriate for the system (because you have skipped past its version number), an error message may be provided. During the update, messages and a progress meter appear to indicate that the update is proceeding. The installation portion of the update takes about half an hour to complete; however, the full upgrade process may not be complete at that point. See later regarding additional firmware upgrades that may take place following the reboot.
While the update is in progress, up until the reboot and following the reboot during any firmware upgrades, it is non-disruptive: the controller continues to provide data services to clients. If the system software fails during the upgrade, it reboots and continues running the software from before the upgrade. Important: Do not perform a cluster takeover operation or a reboot while an update is in progress.
Following the post-upgrade reboot, component firmware is updated (see Hardware Firmware Updates) which takes additional time that depends on the size of the system configuration and the amount of firmware that has changed since the previously installed version was delivered. Very large configurations may take several hours to complete all firmware upgrades after the update itself has been applied.
For details on the update process using the BUI or CLI, review the following sections.
Best practices include verifying several preconditions prior to applying an update. Whenever possible, administrators should ensure that these preconditions are satisfied immediately prior to applying an update on the storage controller. In a clustered environment, these should be verified on both storage controllers before applying the update to either one.
Ensure that any resilvering operations have completed. This can be observed in Configuration > Storage or the equivalent CLI context. For more information, see Chapter 5, Storage Configuration, in Oracle ZFS Storage Appliance Administration Guide .
Ensure that there are no active problems as described in Problems.
Verify that firmware updates are not in progress.
Check the most recent product release notes for additional preconditions that should be observed for the software release to which you are upgrading.
System-level health checks are provided to help ensure that no pathologies interfere with the software update. If a problem is encountered, it is noted in the Alert Log and the update process is aborted. System software updates do not proceed until all problems have been corrected.
You can manually run the same health checks in advance of any planned update. This allows you to check the state of the system prior to scheduling an update maintenance window so you can correct any problems that could interfere with the update process. Any problem report that is issued by a manual health check is identical to that issued by the health checks integrated in the update process. As with the integrated health checks, you are presented with a link to the Alert Log, as described in Alerts , when problems are found. If no problems are found, the System Ready state transitions to Yes to indicate that the system is ready for software updates.
After you select and start an update, update health checks may be issued from the software update dialog box in the BUI by clicking Check.
Figure 3-1 Starting the Update Health Checks in the BUI
The system remains in the Unchecked state until the Check button is clicked. During the health check operation, an indicator shows its progress.
Figure 3-2 Update Health Checks in Progress in the BUI
After completion, the System Ready state changes to Yes or No with a link to the Alert Log.
Figure 3-3 Completed Update Health Checks in the BUI
To execute the update health checks via the CLI, execute the upgrade command in the maintenance system updates context after selecting the update media:
zfs-appliance:maintenance system updates:firstname.lastname@example.org,1-1.6> upgrade This procedure will consume several minutes and requires a system reboot upon successful update, but can be aborted with [Control-C] at any time prior to reboot. A health check will validate system readiness before an update is attempted, and may also be executed independently using the check command. Are you sure? (Y/N) Healthcheck running ... / Healthcheck completed. There are no issues at this time which would cause an upgrade to this media to be aborted.
Prior to the actual update, health checks are performed automatically when an update is started. If an update health check fails, it can cause an update to abort (see following example). Update health checks only validate issues that can impact updates.
Figure 3-4 Example BUI and CLI Update Health Checks Failures
zfs-appliance:maintenance system updates email@example.com,1-1.6> upgrade This procedure will consume several minutes and requires a system reboot upon successful update, but can be aborted with [Control-C] at any time prior to reboot. A health check will validate system readiness before an update is attempted, and may also be executed independently using the check command. Are you sure? (Y/N) error: System is not in an upgradeable state: prerequisite healthcheck reports problems. See alert log for more.
After an update health check failure, you can review the Alert Log and take action to resolve each failure based on the message in the log. The following table lists the update health check failures that can block an update, and describes the associated Alert Log message and recommended order of steps you can take to resolve the issue. For component faults, follow the instructions for removal and installation found in the maintenance procedures for your controller.
Take the following steps in the order listed above to resolve the issue detected during the upgrade health check.
Each update may come with new firmware or updates to external resources. In general, these updates are backwards-compatible and applied automatically without user intervention. There are exceptions, however, for non-reversible updates. These updates involve updating a resource external to the system software in a way that is incompatible with older software releases. After the update is applied, rolling back to previous versions results in undefined behavior. For these updates, you are always given an explicit option of applying them automatically during upgrade or applying them after the fact. They are, therefore, referred to as "deferred updates."
When applying an update to a version with incompatible version changes, you are given an option to apply these version changes as part of the upgrade. For each version change, the benefits of applying the change are presented to you. The default is to not apply them, requiring you to return to the updates view and apply them once the system has rebooted after the upgrade is applied. This allows you to verify that the rest of the software is functional and a rollback is not required before applying the update.
If you elect to not apply deferred updates during an upgrade, you can return to the updates view at any point to apply the update. If deferred updates are available for the current software version, they appear as a list below the current set of available updates, with an "Apply" button to apply the updates. Deferred updates in a cluster take effect on both storage controllers simultaneously, and can only be applied while both controllers are operational. Because deferred updates are listed only for resources present on the local storage controller, in a cluster it may be the case that deferred updates are available only for resources active on the peer controller. In a cluster, it is therefore necessary to check both storage controllers to determine the availability of deferred updates.
Following the completion of the update process, the system reboots automatically. If you have the serial console open, you will notice during this reboot that multiple GRUB menu entries are available, ordered from the newest software (at the top) to the oldest software (at the bottom). The default menu entry is at the top -- the new software to which you just updated. If you do nothing, this entry boots by default, completing the update. The previous entries are rollback targets that can be used to initiate a rollback to previous versions of the system software. Rollback is discussed later.
GNU GRUB version 0.97 (612K lower / 2087424K upper memory) +-------------------------------------------------------------------------+ | Sun ZFS Storage 7120 2013.06.05.0.0,1-1.6 | | Sun ZFS Storage 7120 2011.04.24.4.2,1-1.28 | | | +-------------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, or 'c' for a command-line.
As the system boots up using the new system software, you will see some special messages on the first boot indicating that an update is completing and noting the previous and new versions of the system software:
SunOS Release 5.11 Version firstname.lastname@example.org,1-1.6 64-bit Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved. System update in progress. Updating from: email@example.com,1-1.28 Updating to: firstname.lastname@example.org,1-1.6 Cloning active datasets ...... done. Upgrading /var/ak/home ... 16 blocks Upgrading /etc/svc/profile ... 176 blocks Upgrading /var/apache2 ... 4432 blocks Upgrading /var/sadm ... 5040 blocks Upgrading /var/svc ... 0 blocks Upgrading /var/dhcp/duid ... done. Upgrading /var/pkg ... 208800 blocks Upgrading /var/ak/logadm.conf ... done. Adjusting system/dump and system/cores ... done. Upgrading /var/crypto/pkcs11.conf ... done. Updating system logs ... done. Starting primordial svc.configd Upgrading SMF repository. This may take several minutes. Upgrading from Version 5 to Version 6 : 11570 of 11570 rows upgraded Upgrading from Version 6 to Version 7 : 6305 of 6305 rows upgraded Upgrading from Version 7 to Version 8 : SMF repository upgrade complete SMF online in 180 seconds Sanitizing manifestfiles properties ... done. Loading smf(5) service descriptions: 162/162 svccfg: Loaded 162 smf(5) service descriptions Transitioning NFS server properties ... done. Re-enabling auditing of Solaris commands ... done. Transitioning network/initial IPMP properties to network/ipmp ... done. Transitioning name service properties ... done. Transitioning CIFS server properties ... done. Preparing for service import ... done. Importing adconf.xml ... done. ... Configuring appliance/kit/identity:default ... done. Applying service layer ak_generic ... done. Refreshing services: done. Applying service layer ak_nas ... done. Refreshing services: done. Applying service layer ak_SUNW,iwashi_plus ... done. Refreshing services: done. Applying service profile ak_generic ... done. Applying profile upgrade/akinstall.xml ... done. Applying layer upgrade/composite.svc ... done. Cleaning up services ... done. Shutting down svc.configd ... done. Configuring devices. Configuring network devices. Sun ZFS Storage 7120 Version ak/SUNW,email@example.com,1-1.6 Copyright (c) 2008, 2013, Oracle and/or its affiliates. All rights reserved. dorab console login: