Dell OS10 Firmware Upgrade: ONIE vs In-Place Image Install

Dell PowerSwitch/S-Series platforms running SmartFabric OS10 offer two fundamentally different update paths, and choosing the wrong one costs a maintenance window. The in-place upgrade keeps the startup configuration; the ONIE path rebuilds partitions and wipes everything. This guide explains when each applies, the exact CLI sequence for both, and the peer-by-peer ordering that keeps a VLT pair passing traffic during the upgrade.

Choosing the Path

• In-place OS10 upgrade - copy the OS10 .bin onto the switch, stage it with image install, reload. Startup configuration is preserved. This is the default choice for routine version moves.
• ONIE-based install - recreates partitions and removes the OS and configuration. Required when moving from ONIE to OS10 for the first time, when recovering a corrupt image, or when Dell release notes demand a clean baseline.

Never update ONIE and OS10 at the same time. ONIE comes first, then OS10; staging both at once is how switches end up booting to the ONIE prompt on a Sunday morning.

What Actually Changes on Each Path

It helps to know exactly what each path does to the switch before you pick one, because the difference is not simply "keeps config" versus "wipes config".

The practical rule: in-place unless something is broken. Use ONIE when the requirement is a known-good baseline rather than a version move.

Before You Begin: Images, Checksums and Space

Four checks prevent most failed maintenance windows. Do them in order, before the window opens.

1. Get the right image from Dell's support site. The OS10 Enterprise installer package carries its version and platform in the filename — for example PKGS_OS10-Enterprise-10.5.3.2.89buster-installer-x86_64.bin. Confirm the release notes list your exact platform and your target version as supported on the version currently installed.
2. Verify the download on the file server, not on the switch. Compare the published checksum before transferring:

   sha256sum PKGS_OS10-Enterprise-10.5.3.2.89buster-installer-x86_64.bin
   md5sum   PKGS_OS10-Enterprise-10.5.3.2.89buster-installer-x86_64.bin

3. Back up the configuration and record the current state. Even an in-place upgrade that preserves configuration should be preceded by a copy you can compare against afterwards:

   OS10# copy running-configuration scp://admin@10.0.0.50/nodename-backup-runconfig.txt
   OS10# show version
   OS10# show image firmware
   OS10# show interface port-channel summary
   OS10# show vlt

4. Check the local storage. The switch must hold the downloaded package before install. Verify free space with dir image, and delete old images you no longer need with image delete image://... if space is tight.

A console session (USB serial or terminal server) should be attached for every upgrade path. SSH survives most reloads, but the moments where an upgrade fails are exactly the moments the management interface does not come back. Our OS10 out-of-band management and VRF notes cover the management path you should keep as the fallback, and OS10 zero-touch deployment explains the automated path if the switch is going to be re-provisioned anyway.

In-Place Upgrade Steps

OS10# copy running-configuration scp://admin@10.0.0.50/nodename-backup-runconfig.txt
OS10# image download scp://admin@10.0.0.50//images/PKGS_OS10-Enterprise-installer.bin
OS10# image install image://PKGS_OS10-Enterprise-installer.bin
OS10# show image firmware
OS10# reload

Back up the running configuration before staging, verify the image with dir image, then confirm the staged entry with show image firmware. If the switch reports that prerequisites are not met, fall back to the ONIE procedure rather than forcing the install.

Three details make the difference between a routine upgrade and a firefighting session. First, image download only fetches the package into switch storage — nothing is activated by it, and repeating it is harmless. Second, image install stages the image and makes it the next boot image, which is why show image firmware must be checked before the reload: if the staged entry shows the old version, the reload will simply boot the old version. Third, the reload prompt asks whether to save the configuration; answer yes when the intent is to keep the current configuration, and only answer no on a path where you have already deleted the startup configuration or have a deliberate backup to restore.

OS10# dir image
OS10# show image firmware
OS10# show version
OS10# image delete image://PKGS_OS10-Enterprise-installer.bin

Delete the old package after the upgrade is verified, not before — it is the fastest rollback asset you have.

ONIE Update and Firmware Refresh

OS10# image install image://onie-updater-x86_64-dellemc_s5200_c3538-r0.3.40.1.1-6.bin
OS10# show image firmware
OS10# reload
OS10# system "/mnt/onie-boot/onie/tools/bin/onie-version"
OS10# image install image://onie-firmware-x86_64-dellemc_s5200_c3538-r0.3.40.5.1-20.bin
OS10# reload

The ONIE firmware step runs from ONIE Update Mode and takes roughly 25 minutes; the switch reloads itself once when it completes. Expect two or three minutes for the ONIE software stage and a console session you can leave attached.

Two distinctions matter here. ONIE update mode updates the ONIE boot loader while leaving the NOS in place — it is what the two sequences above do. ONIE install mode is the environment that runs when no NOS is present or when the user explicitly asks for an install; it offers the installer menu and networking tools. Do not expect to find onie-nos-install inside an OS10 shell, and do not expect OS10 commands inside ONIE. During the firmware refresh, do not power-cycle the switch, do not interrupt the console, and do not start a second install: the process writes boot sectors and an interrupted write is how a switch ends up needing a USB recovery image.

A Clean OS10 Install from ONIE

When the switch is already in ONIE install mode, bring the management address up and pull the image straight from a file server:

ONIE:/ # onie-nos-install http://10.0.0.50/PKGS_OS10-Enterprise-10.5.3.2.89buster-installer-x86_64.bin

The switch loads both partitions, then presents the OS10 login prompt with the factory admin/admin credentials. Do not rename the .bin - the installer validates the filename.

In practice the switch must be able to reach the file server first, so the full sequence usually starts with the ONIE discovery tools:

ONIE:/ # onie-discovery-stop
ONIE:/ # ip addr add 10.0.0.60/24 dev eth0
ONIE:/ # ip link set eth0 up
ONIE:/ # ip route add default via 10.0.0.1
ONIE:/ # ping -c 3 10.0.0.50
ONIE:/ # onie-nos-install http://10.0.0.50/PKGS_OS10-Enterprise-10.5.3.2.89buster-installer-x86_64.bin

DHCP is the default in ONIE, so if a DHCP server answers on the management network you can skip the static addressing and simply confirm the address with ip addr show eth0. If the file server is reachable over SCP or TFTP instead of HTTP, the same onie-nos-install command accepts those transports. When the install finishes, expect the switch to reboot into OS10 with an empty configuration — no hostname, no management address, no VLT domain, and ZTP potentially waiting to run.

VLT Pairs: One Peer at a Time

On a VLT pair, update one peer completely, verify that the other is forwarding, then repeat on the second peer. Traffic then rides the surviving peer for the whole window. After each reload, validate the peer link, port channels and routing adjacencies; the checks worth automating are listed in Dell OS10 VLT peer routing configuration and the post-upgrade baseline in Dell OS10 basic switch management. Remember that the ONIE route erases configuration and installed licences, so that path needs a configuration restore step in the runbook.

Expand that into an explicit timeline so nobody has to improvise at 02:00:

Two failure modes are worth naming. If VLT does not re-establish after a peer reloads, the usual cause is a version mismatch in the VLT domain configuration or an interface that came back down — check the peer link first, then the backup link. And if the surviving peer shows unknown unicast flooding after the first peer's reload, verify that the peer link is up and that the port-channel members on both sides are in the expected state; the traffic is often arriving fine while the peer link has not yet converged.

Post-Upgrade Validation Checklist

OS10# show version
OS10# show image firmware
OS10# show vlt
OS10# show vlt counters
OS10# show interface port-channel summary
OS10# show interface status
OS10# show ip bgp summary
OS10# show ip ospf neighbor
OS10# show running-configuration vlt

Work through it top to bottom: version first (did the image actually change?), then VLT and port channels (is the data path intact?), then routing (is the control plane back?), then the interface error counters. An interface that comes back with CRC or input errors after an upgrade is usually a cabling or optics issue that the reload merely exposed — but treat it as part of the upgrade until proven otherwise, because a mid-upgrade link flap is often the first visible symptom of a hardware problem. The related per-peer checks live in OS10 VLT troubleshooting with show vlt commands.

Troubleshooting Common Failures

• "Prerequisites are not met" from image install. The platform, the current version, or the available storage does not satisfy the package's requirements. Check the release notes and the free space with dir image; if the constraint is the current version, use the ONIE path.
• Switch boots back into the old version. The image was downloaded but never installed, or the install did not complete. Re-run image install and confirm the staged entry with show image firmware before reloading.
• Switch boots to the ONIE prompt. The OS10 partition is unusable — either a failed install or an interrupted firmware write. Recover with onie-nos-install and restore the configuration from backup.
• Install progress stops at a percentage. Do not power-cycle. Check the console for a stalled transport (the file server may have dropped the connection) and be prepared to restart the install; a forced power cycle during a partition write turns a software problem into a recovery procedure.
• Configuration and licences gone after the upgrade. You took the ONIE path, or the reload was answered with "yes" when the startup configuration had already been deleted. Restore from the backup file and re-apply the licence.
• ZTP starts after a clean install. Expected on a freshly installed switch with an empty configuration; it is covered in OS10 zero-touch deployment.
• A downgrade fails. Not every version pair supports a live downgrade. In-place downgrades usually require a factory reset of the configuration first; the procedure is documented in Dell OS10 factory reset with delete startup-configuration.

Which Path Should You Choose?

• Routine version move on a healthy switch: in-place. Back up, image download, image install, verify, reload, validate.
• Dell release notes require a clean baseline, or the image is corrupt: ONIE install, then restore configuration.
• ONIE itself is older than the supported matrix: ONIE update first, reload, confirm the version, and only then move OS10.
• VLT pair: whichever path you use, apply it one peer at a time and gate each step on verification.

If you are coming from another vendor's upgrade model, the closest equivalents are Cisco's install-mode add/activate/commit workflow — see IOS XE install mode upgrade — and Juniper's request system software add with its snapshot-based rollback, covered in Junos software upgrade. The same discipline applies to all of them: know what survives the upgrade, verify the staged image before you reload, and never upgrade both halves of a redundant pair at once.

原文链接：https://www.dell.com/support/manuals/en-us/smartfabric-os10-emp-partner/ee-upgrade-downgrade/update-onie-and-onie-firmware