NetApp firmware upgrades: disks, shelves, SP/BMC and BIOS

01Identify what is being upgraded

ONTAP software, drive firmware, shelf-module firmware, controller management firmware and DQP solve different problems. An ONTAP image can bundle some firmware, but it does not make every installed hardware component current. Inventory the actual model and active version first. A firmware file for a similarly named component is not a substitute for the exact supported package.

1. Create one inventory row per component: node, owner, model/part number, serial or shelf/module slot, current revision, approved target, package checksum and release instructions.
2. Record whether the package installation, download or activation can reboot a component, temporarily remove a path, interrupt management access or affect client I/O. Use that effect to choose the window and service test.

02Capture firmware and hardware prechecks

1. Save active disk and shelf-module revisions, ownership and redundant connectivity. Compare the full drive model/part identity with the downloaded package’s supported-device list.
2. Confirm both HA partners are available and no takeover/giveback or conflicting maintenance is underway. Resolve degraded RAID, reconstruction, broken-path and power/environment issues before firmware work.
3. Verify SP/BMC reachability and a second authorized management/console path. Have a client representative monitor a real transaction; hardware health and client service must both be observed.

cluster show
storage failover show
system health status show
system health alert show
storage aggregate show
storage disk show -broken
storage disk show -fields model,firmware-revision
storage disk option show
storage shelf show
storage shelf show -module
storage shelf show -connectivity
system service-processor show
system service-processor image show -instance
storage dqp show -instance

03Prepare packages and update sequencing

Use the NetApp Support Site and the exact component release instructions. Keep the downloaded files and checksums unchanged. For disk firmware, update DQP first. For controller/adapter dependencies, follow the package’s specified order rather than assuming every environment uses disk, shelf, SP and BIOS in one universal sequence. Staging may start an automatic firmware action, so perform it within the approved change process.

1. Read package prerequisites, supported ONTAP/platform versions, intermediate firmware requirements, known issues, expected restart behavior and recovery instructions.
2. Stage only the approved component file on the controlled server. Keep disk, shelf, SP/BMC and service images in separate paths so a URL cannot accidentally reference the wrong file.
3. Check DQP on every relevant node and complete the DQP guide before adding a new drive type or updating drive firmware. Record automatic/background policies before changing them.

# Example directory layout on the staging server:
# /srv/netapp/firmware/disks/APPROVED_DISK_PACKAGE.zip
# /srv/netapp/firmware/shelves/APPROVED_SHELF_PACKAGE.zip
# /srv/netapp/firmware/sp-bmc/APPROVED_SP_BMC_PACKAGE.zip
# /srv/netapp/firmware/system/APPROVED_SERVICE_IMAGE.zip
# /srv/netapp/dqp/qual_devices.zip

04Preferred disk method: enable supported background updating

NetApp recommends the automatic background disk firmware method for HA clusters. Inspect the existing setting first. Background work can be deferred when RAID, a plex or a volume is not in a suitable state, or reconstruction is active. A waiting disk is not a reason to bypass those safeguards with a foreground command. Enabling the option is a configuration change; follow your approved policy.

1. Confirm the applicable drive type and firmware package support this method. Restore normal RAID/storage state before expecting background work to finish.
2. Retain the pre-change policy and the approved final policy. Do not disable background updating merely to make the process run faster.
3. Keep application and hardware monitoring active during download/installation. A completed file transfer and a completed hardware update are different milestones.

storage disk option show -node lab-01
storage disk option show -node lab-02
# If the approved policy requires background updates and they are off:
storage disk option modify -node lab-01 -bkg-firmware-update on
storage disk option modify -node lab-02 -bkg-firmware-update on
storage disk option show

05Download the drive firmware to each relevant node

Download to each node that needs the package. A firmware file staged on one HA partner should not be assumed to exist on the other. Do not manually extract, rename or copy files into ONTAP system directories to work around a packaging problem. Correct the package or investigate the transfer through its documented workflow.

1. Confirm transfer and package processing succeeded for lab-01, then perform and confirm the lab-02 transfer. For a larger cluster, enumerate all relevant nodes in the change plan.
2. With the supported background policy enabled, monitor eligibility and progress. Do not issue storage disk firmware update as an extra mandatory step in this preferred method.
3. If no update occurs, compare installed revisions and package compatibility first. An already-current drive can legitimately require no change.

set -privilege advanced
storage firmware download -node lab-01 -package-url http://192.0.2.80:8080/firmware/disks/APPROVED_DISK_PACKAGE.zip
storage firmware download -node lab-02 -package-url http://192.0.2.80:8080/firmware/disks/APPROVED_DISK_PACKAGE.zip
storage disk firmware show-update-status
set -privilege admin

06Monitor background disks and validate the actual revisions

Different drive models may require different accepted firmware strings. Compare each model group with its approved package instead of demanding one revision across every drive. In a synthetic case, 46 drives complete and two remain pending during a reconstruction: leave the change open until reconstruction clears and the two drives complete or have an explicitly accepted exception.

set -privilege advanced
storage disk firmware show-update-status -instance
set -privilege admin
storage disk show -fields model,firmware-revision
storage disk show -broken
storage aggregate show
system health alert show

07Manual disk command: a separate potentially disruptive branch

The command reference warns that a manual disk firmware update can make affected disks inaccessible and interrupt sessions. Use this branch only when the exact package/platform procedure and change plan call for it. The pair must be healthy and outside takeover/giveback; follow the documented session and application coordination requirements. It is not a fast replacement for the recommended background method.

1. Stage the approved drive firmware on both partners and verify current DQP. Confirm the manual method’s service-impact plan with application owners before issuing the command.
2. Execute for one node only. Review the warning and monitor its console, disks, RAID and client impact until that node’s work completes.
3. Verify actual revisions and normal storage state before starting the partner. The following two blocks are separated deliberately; they must not be pasted as an unattended batch.

# First node only — potentially disruptive:
set -privilege advanced
storage disk firmware update -node lab-01
set -privilege admin
storage disk show -fields model,firmware-revision
storage failover show
# STOP: verify lab-01 completion and service acceptance.
# Only then, if the approved manual procedure calls for the partner:
set -privilege advanced
storage disk firmware update -node lab-02
set -privilege admin

08Shelf firmware: inspect modules and preserve redundant paths

Shelf firmware targets IOM/NSM modules rather than drive firmware. The shelf name is the identifier shown by ONTAP, not a label guessed from the rack. Confirm module type, each module’s current revision, path redundancy and the package’s supported upgrade behavior. SAS and NVMe shelves can have different dependencies and activation behavior.

1. Record the shelf and both module slots, current revisions and expected target. Verify the physical/cabling design against the model guide.
2. Resolve any missing redundant connection or module/environment fault before initiating work. A management path alone does not prove both storage paths are healthy.
3. Coordinate package staging with the window and existing automatic update settings. Use a shelf-specific update scope rather than unintentionally targeting every shelf.

storage shelf show
storage shelf show -shelf 1.2 -module
storage shelf show -shelf 1.2 -connectivity
system health alert show

09Download and start the approved shelf update

1. Verify successful staging on each relevant node. If the package/automatic mechanism has already begun the update, monitor that action rather than starting a conflicting manual trigger.
2. When a manual trigger is required, use the confirmed shelf name. The bare storage shelf firmware update command targets all shelves; this example intentionally selects only 1.2.
3. Wait for completion and observe module/path state and client I/O. Do not power-cycle a shelf or controller to make progress appear faster.

set -privilege advanced
storage firmware download -node lab-01 -package-url http://192.0.2.80:8080/firmware/shelves/APPROVED_SHELF_PACKAGE.zip
storage firmware download -node lab-02 -package-url http://192.0.2.80:8080/firmware/shelves/APPROVED_SHELF_PACKAGE.zip
storage shelf firmware show-update-status
# If the package workflow requires a manual trigger and no update is already active:
storage shelf firmware update -shelf 1.2
storage shelf firmware show-update-status -instance
set -privilege admin

10Shelf postchecks: active modules and connectivity

An idle shelf updater means no action is currently active; it does not by itself prove both modules have the approved active firmware. Compare module revisions and operational state with the package expectation and restore all required storage paths. If one module remains on the old revision, inspect the specific module and update evidence before scheduling another attempt.

set -privilege advanced
storage shelf firmware show-update-status -instance
set -privilege admin
storage shelf show -shelf 1.2 -module
storage shelf show -shelf 1.2 -connectivity
storage shelf show -errors
storage disk show -broken
storage aggregate show
storage failover show

11SP/BMC: verify out-of-band access and prepare the controller

NetApp’s manual firmware preparation recommends rebooting SP/BMC before its update. This reboots the management controller, not an instruction to reboot the ONTAP data-serving node. Expect temporary out-of-band access loss and confirm the controller returns before continuing. Avoid starting both management-controller updates together when that would remove your independent recovery access.

1. Verify the current active image, any in-progress update and the existing automatic update policy. Keep a separate cluster session and an authorized alternate console path.
2. Reboot the intended SP/BMC only when its package workflow and window are ready. Wait until it reports online and its management access is usable again.
3. Obtain the approved controller-specific image and keep its compatibility/prechecks enabled. A BIOS service image and an SP/BMC image are different packages.

system service-processor show -node lab-01
system service-processor image show -node lab-01 -instance
system service-processor image update-progress show -node lab-01
# In the approved window, following the component update instructions:
system service-processor reboot-sp -node lab-01

12Stage and apply an approved SP/BMC package

The -baseline true alternative installs the firmware bundled with the currently running ONTAP release. It is not a command for selecting the newest firmware and should not be used as a routine upgrade shortcut. A return to baseline is a separate reviewed recovery decision.

1. Fetch the package to the intended node and inspect the repository details. Substitute the actual filename rather than assuming the placeholder is valid. Automatic firmware settings can affect what starts after download; check progress before issuing a duplicate install request.
2. Apply the compatible image for lab-01 through the package workflow. Do not disable prerequisite checks to bypass a baseline or compatibility error.
3. Monitor completion, active version and out-of-band access. Only after lab-01 is accepted should you repeat preparation, staging and validation for lab-02 with its correct package.

set -privilege advanced
system node image get -node lab-01 -package http://192.0.2.80:8080/firmware/sp-bmc/APPROVED_SP_BMC_PACKAGE.zip
system node image package show -node lab-01 -instance
set -privilege admin
system service-processor image update-progress show -node lab-01
# Continue only if automatic installation has not already started or completed:
# Use the exact SP/BMC package filename listed by the repository:
system service-processor image update -node lab-01 -package APPROVED_SP_BMC_PACKAGE.zip
system service-processor image update-progress show -node lab-01

13SP/BMC postchecks and failed-update handling

Check completion percentage/end state together with the active firmware and a real authorized management login. A progress display alone cannot prove recovery access is usable. If the update fails, retain the error, package identity, source/target versions and controller console state; investigate before retrying. The update command does not automatically retry a failure.

1. Confirm no intended management-controller update remains active and each SP/BMC is online on the accepted revision.
2. Test an authorized out-of-band connection without issuing a power command. Confirm ONTAP data service, HA and hardware alerts remain normal.
3. For a compatibility rejection or unreachable SP/BMC, follow the component’s recovery procedure or NetApp Support guidance. Keep the other controller’s access intact while diagnosing.

system service-processor image update-progress show
system service-processor image show -instance
system service-processor show
cluster show
storage failover show
system health alert show
event log show -time >1h

14BIOS/LOADER pre-staging for clusters already on 9.17.1 or later

This branch has a specific prerequisite: all cluster nodes must already run ONTAP 9.17.1 or later. It is not the procedure to apply blindly to the 9.14.1 starting point in the ONTAP example. Obtain a supported newer BIOS/LOADER service image and verify its relationship to the firmware bundled with the planned target ONTAP image.

1. Validate the prerequisite, platform support and approved service image before downloading it to each intended node’s boot device.
2. Inspect boot-media and running BIOS/LOADER versions. At this point newer firmware can be staged while the old firmware is still running. Retain both values.
3. Follow the ANDU guide with the actual supported current/target software builds. The documented pre-stage workflow preserves newer supported boot-media firmware and activates it through the normal upgrade reboot.
4. After ANDU, rerun system node firmware bootmedia show. Verify the intended running versions, not only the staged values, and complete the HA/client postchecks.

set -privilege advanced
system node firmware download -node lab-01 -package http://192.0.2.80:8080/firmware/system/APPROVED_SERVICE_IMAGE.zip
system node firmware download -node lab-02 -package http://192.0.2.80:8080/firmware/system/APPROVED_SERVICE_IMAGE.zip
set -privilege admin
system node firmware bootmedia show

15Earlier BIOS/LOADER activation: package and platform instructions control the console steps

For an earlier or separately activated service image, do not assume the 9.17.1+ preservation behavior. The system firmware download reference describes staging to the boot device and activation through a reboot/firmware prompt. The exact platform/package instructions determine how to reach that prompt, which firmware is flashed and when the node can return to service. A download success alone does not activate firmware.

1. Prepare the exact model’s supported HA/maintenance and console workflow before the window, including host resilience and giveback acceptance. This generic guide cannot supply a universal boot-interrupt sequence for every controller.
2. Service one controller at a time through that approved workflow. Establish the required takeover/isolated maintenance state before any controller reboot or LOADER action.
3. Only at the correct firmware prompt, and only when the package instructions call for it, perform the documented flash command. Keep power stable and wait for explicit completion.
4. Boot/return the node and perform version, HA, storage-path and client acceptance before the partner is serviced. Record the console transcript and actual active versions.

# ONTAP staging example — not a complete activation by itself:
set -privilege advanced
system node firmware download -node lab-01 -package http://192.0.2.80:8080/firmware/system/APPROVED_SERVICE_IMAGE.zip
set -privilege admin
# At the isolated node's LOADER prompt ONLY if its platform/package procedure specifies it:
update_flash
# Continue boot using the exact platform procedure after flash completion.

16ACP firmware for applicable legacy shelves

ACP is a shelf management component used by applicable shelf designs; do not assume every current shelf has the same ACP workflow. The storage firmware download reference distinguishes ACP, drive and shelf-module payloads. Confirm that the exact legacy package calls for ACP installation and use the supported shelf documentation.

1. Record the ACP topology, current connectivity and the supported package. Stage to the nodes specified in the exact shelf procedure.
2. Use the documented ACP installation operation only for those applicable systems, then verify ACP and storage connectivity.
3. Do not use an ACP command to try to update an NVMe shelf module, SP/BMC or drive. Each of those has its own package and command family.

storage shelf acp show
set -privilege advanced
storage firmware download -node lab-01 -package-url http://192.0.2.80:8080/firmware/acp/APPROVED_ACP_PACKAGE.zip
# Applicable legacy procedure only:
system node run -node lab-01 -command "storage download acp"
set -privilege admin
storage shelf acp show
system health alert show

17Firmware change closure and a worked decision example

Synthetic example: shelf 1.2 reports idle, but slot B still shows the previous module revision and one path is missing. The correct conclusion is that the shelf has not passed acceptance. Preserve its module/connection output, inspect the specific failure and keep the change open. Rebooting both controllers or rerunning a cluster-wide update would add risk without explaining the failure.

1. Run the separate postcheck guide, selecting the rows relevant to disks, shelves, SP/BMC or BIOS. Verify active revisions as well as a completed updater.
2. If the procedure changed a policy, restore only the policy explicitly required by the approved final state; do not undo a deliberately enabled background-update standard.
3. Close maintenance after application acceptance and retain exceptions with component identity, reason and follow-up owner.

system node autosupport invoke -node * -type all -message "FIRMWARE_CHANGE_ACCEPTED"
system node autosupport invoke -node * -type all -message "MAINT=END"