CliDeck
PlatformLog in
Workspace

Arista EOS Boot Image Checks: Separate Running Software from Next Boot

Runbooks
#arista#operational-evidence#runbooks#remote-operations#Runbooks
← Back to Blog

Short answer

Record the active EOS version, inspect boot-config's selected image path and check that the intended image is available in the expected storage location. Keep running software and next-boot selection as separate facts. A switch that is healthy now can still have an unsuitable or unavailable next-boot image.

This preflight applies to owned or customer-authorized Arista EOS switches using the documented EOS CLI command family. Current manual pages are labelled EOS 4.36.2F, but examples include older builds; confirm the actual hardware, EOS and boot environment. The workflow is an inspection, not an upgrade or permission to reload.

Establish the active software

Collect the device's current identity and software information:

show version

Record the actual model and Software image version. Retain architecture and other relevant build details when displayed. Match the device to the approved maintenance record using private identifiers.

A filename elsewhere in flash does not override this observation. The switch's active version is a fact about what is running now, not a promise about the file that a subsequent normal boot will select.

If identity or software is unexpected, resolve it before treating the planned image as appropriate.

Inspect the next-boot selection

From an authorized EOS CLI session with the necessary permissions, display:

show boot-config

Preserve the Software image path exactly, including storage location and spelling. Boot-config identifies the image Aboot uses during a normal uninterrupted boot. Startup-config is the configuration loaded at boot, while running-config is the current active configuration; these are separate records.

Do not enter a boot system command simply to make the selection match the work order. That is a boot change requiring its own reviewed procedure.

Boot-config output can expose an encrypted Aboot password and other sensitive material. Keep the raw capture private. For a shared handoff, retain the needed image-path facts and redact password hashes, certificates and identifying operational details.

Check the selected storage location

For an image selected on local flash, inspect its directory:

dir flash:

Match the exact selected filename with the directory entry. Record the file size and available space where displayed. A similar name or a second older SWI file is not proof that the selected path exists.

If boot-config points to USB or another supported location, do not report a flash listing as verification of that target. Use the appropriate documented inspection for the actual path, and confirm that any required medium will remain available during the maintenance event.

A missing or ambiguous target is a stop condition. Do not delete files, copy images or change the path as an incidental cleanup step.

Keep availability, integrity and compatibility separate

A directory entry proves only that an entry is present at the time of inspection. It does not verify a complete transfer, image integrity or support for the appliance.

The vendor upgrade workflow includes an image verification step against the checksum supplied through the authorized image distribution channel. Before a separately approved upgrade, use the documented verification for the exact file and preserve the comparison result. A checksum comparison checks file consistency with that reference; it does not establish platform compatibility or successful boot.

Read the intended release's platform support and upgrade/downgrade requirements. Do not infer compatibility from a filename, current uptime or available flash space.

Space also belongs to the preflight. The documented standard workflow accounts for additional space needed during image loading. Use the requirements for the actual platform and release rather than removing diagnostic or rollback artifacts to meet a guessed threshold.

Treat multiple supervisors as a different scope

The simple local inspection above does not certify both supervisors of a modular switch. Image synchronization, supervisor state and upgrade method need the platform's dedicated procedure.

Likewise, it does not prove an MLAG peer is ready or validate a fast-boot/SSU path. Keep those dependencies explicit. A result for one switch must not be silently promoted into readiness for a pair or an entire change window.

Verification note: criteria for boot-image preflight

A complete record separates the running EOS version, next-boot image selection and storage availability. It identifies the actual platform/build, records integrity and compatibility checks as completed or pending, and names any media or supervisor dependency.

These are acceptance criteria, not a successful reboot report. No EOS image transfer, checksum execution, upgrade or physical switch test is claimed. An available file alone is insufficient to approve recovery or reload.

Use the remote upgrade session checklist for the separate maintenance decision. Keep Arista recovery and wipe scope distinct from an image preflight, and retain the record in the CliDeck workspace.

Who this is for

This guide is for operations teams, incident responders, network engineers, and system administrators who need to prepare, run, verify, and document operational terminal work on SSH, serial, browser terminal, and infrastructure operations workflows.

When to use this

Use this guide when:

  • Several commands or checks must be repeated safely.
  • Another engineer, customer, onsite technician, or vendor may need context.
  • The work should produce notes, logs, verification, or a clear handoff.

When not to use this

Do not use this guide when:

  • You do not own or have authorization to work on the device.
  • The device is outside your approved change, recovery, or processing scope.
  • The task may expose customer data, secrets, licenses, or credentials that you are not allowed to view or store.
  • The work requires vendor-specific approval, legal approval, or a customer-specific procedure that is not covered here.

Practical runbook format

A runbook does not need to be a complex script. For many operations, it can be a plain command list with notes, expected output, stop conditions, verification steps, and rollback instructions.

What to include

  • Purpose
  • When to use it
  • When not to use it
  • Target system or device
  • Access path
  • Read-only checks
  • Change steps
  • Expected output
  • Stop conditions
  • Rollback steps
  • Verification steps
  • Handoff notes
  • Final summary format

Workflow

  • Define the purpose, target device, access path, and approved scope.
  • Run read-only checks first and record the expected healthy state.
  • Execute commands from the runbook or handoff plan while watching for stop conditions.
  • Verify the final state with independent checks.
  • Summarize commands run, outputs reviewed, exceptions, and handoff notes.

Verification checklist

  • The target device or system is correct.
  • Read-only checks were captured before the work.
  • Stop conditions and rollback notes were available before changes.
  • Final verification checks match the expected result.
  • Notes, logs, and handoff summary are stored where the team can find them.

Common mistakes

  • Starting commands before confirming the target device and scope.
  • Skipping read-only baseline checks.
  • Copying commands without expected output, stop conditions, or rollback notes.
  • Closing the work without a final verification summary.

CliDeck workflow fit

CliDeck Workspace is designed for this kind of operational workflow. Teams can keep terminals, notes, runbooks, logs, and shared sessions in one browser workspace instead of spreading work across terminal windows, chat messages, screenshots, and separate documents.

CliDeck runbooks can be plain command lists, one command per line. Operators can send commands with one click or use auto-run behavior that waits for the prompt before sending the next line where configured.

FAQ

Does a runbook need to be code?

No. A useful runbook can be a plain list of commands, checks, notes, expected output, stop conditions, and verification steps.

Why use a browser workspace for terminal work?

A browser workspace can keep terminals, notes, runbooks, logs, and shared sessions together, which helps during incidents, handoffs, maintenance windows, and remote support.

Can shared terminal sessions be safer than screen sharing?

Yes, when implemented with clear view/type permissions. The helper can see the relevant terminal context without taking over the operator’s entire desktop.

Can CliDeck help with this workflow?

Yes. CliDeck Workspace helps organize terminals, runbooks, notes, logs, and shared sessions. Console Server Go is useful when the workflow starts at a rack-side console port.

Related guides