Cisco Catalyst 9200L Upgrade: Fixing “Super Package Already Added”

During an IOS XE upgrade on a standalone Cisco Catalyst 9200L switch, the standard one-shot install command did not proceed as expected. Instead, the switch returned this message:

Super package already added. Add operation not allowed.

The message did not mean that the new image was corrupt. It meant that the Add stage had already completed and the extracted packages were present on the switch. Repeating the Add operation was therefore rejected.

In this case, the upgrade continued with install activate. After the reload and initial verification, install commit was run. The switch was running the target release, booting in Install mode, and the final install state was C, meaning Activated and Committed.

This article documents the actual sequence, the flash-space observations, and the verification steps that prevented an unnecessary restart of the entire upgrade process.

Environment

  • Platform: Cisco Catalyst C9200L-24P-4G
  • Topology: Standalone switch
  • Starting release: Cisco IOS XE 17.9.4a
  • Target release: Cisco IOS XE 17.18.4
  • Boot mode: Install mode
  • Image transfer method: TFTP to local flash

Hostnames, IP addresses, MAC addresses, serial numbers, and environment-specific timestamps have been omitted or generalized.

Pre-Upgrade State

The original software state was checked with:

show install summary

The running 17.9.4a image was displayed with state C:

State (St): I - Inactive, U - Activated & Uncommitted,
            C - Activated & Committed, D - Deactivated & Uncommitted

Type  St  Filename/Version
IMG   C   17.09.04a...

This confirmed that the original release was already committed before the maintenance began.

Other useful pre-upgrade checks include:

show version
show boot
dir flash:
show install summary

Flash Space: Official Guidance and the Actual Result

Cisco's Catalyst 9200 upgrade instructions recommend cleaning up inactive files and ensuring that at least 1 GB of flash space is available to expand a new image.

The observed result in this upgrade was different, but it must be interpreted carefully.

After the target BIN file had been copied to flash and inactive files had been cleaned up, the switch showed:

805228544 bytes free

That is approximately 768 MiB, commonly described during the maintenance as about 800 MB. The upgrade completed successfully with that remaining space.

This does not establish 800 MB as a new minimum requirement. Required space can vary by platform, image, stack size, retained packages, and existing files. The Cisco 1 GB guidance remains the safer planning target. This case only records what succeeded on this specific standalone C9200L and image combination.

Copying the IOS XE Image

The target image was copied from a TFTP server to local flash:

copy tftp: flash:

The image used in this case was:

cat9k_lite_iosxe.17.18.04.SPA.bin

Before installation, verify that the expected file is present and that its size is reasonable:

dir flash:

For a production maintenance procedure, also compare the image hash with the value published by Cisco for the exact downloaded file.

The Standard One-Shot Command

The normal Install-mode command combines the Add, Activate, and Commit stages:

install add file flash:cat9k_lite_iosxe.17.18.04.SPA.bin activate commit

On a normal first attempt, the command performs the following work:

  1. Adds and validates the image.
  2. Extracts the BIN file into package files.
  3. Activates the new package set.
  4. Reloads the switch.
  5. Commits the new software state.

The Error: Super Package Already Added

In this case, running the one-shot command returned:

FAILED: Super package already added. Add operation not allowed.
install remove inactive can be used to discard added packages.

The key phrase is already added. The 17.18.4 package files had already been populated on flash by an earlier Add operation. The switch rejected another Add attempt because it was not starting from a clean, unadded state.

This error should not automatically lead to deleting files or repeating the same command. First determine the current install state.

Checks Before Choosing the Next Command

Use read-only commands to determine whether the target image is inactive, activated, uncommitted, or already committed:

show install summary
show install inactive
show install log
dir flash:

The correct recovery action depends on the output:

  • If the target image is present as an added or inactive package, activation may be the next stage.
  • If the target image is activated but state U, it still requires commit verification and normally an install commit.
  • If the added package must be discarded and restarted, review the files selected by install remove inactive before approving deletion.
  • If the install state is unclear or another operation is running, inspect the install log before changing anything.

The Command Used in This Upgrade

Because the package Add stage had already completed, the actual next command used was:

install activate

No image filename was supplied. The switch identified the added 17.18.4 package set and displayed the packages that would be activated.

It then displayed a reload warning:

This operation may require a reload of the system.
Do you want to proceed? [y/n]

After approval, the activation proceeded and the switch reloaded.

Operational impact: this is a disruptive action. The standalone switch reloads, its ports go down, and traffic is interrupted until the switch returns to service. It should only be executed during an approved maintenance window with console or recovery access available.

Post-Reload Verification and Commit

After the switch returned, the running version, boot mode, boot variable, and installation state were checked:

show version
show boot
show install summary
dir flash:

After confirming that the target release was running correctly, the new software state was committed:

install commit

The final verification confirmed:

  • Running software: IOS XE 17.18.4
  • Mode: INSTALL
  • Boot variable for the next reload: flash:packages.conf
  • Final image state: C
  • Auto abort timer: inactive

The final install summary was equivalent to:

Type  St  Filename/Version
IMG   C   17.18.04...

Auto abort timer: inactive

Why the Final C State Matters

Cisco defines the relevant install states as:

  • I - Inactive
  • U - Activated and Uncommitted
  • C - Activated and Committed
  • D - Deactivated and Uncommitted

In this incident, install activate and install commit were performed as separate steps. The supplied maintenance PDF does not capture the final commit command, but the operator confirmed that it was run. The final show install summary output showed state C, and the auto-abort timer was inactive, independently confirming that the switch finished in a committed state.

Cisco documents Activate and Commit as separate stages when they are not combined in the one-shot command. If the state is U after activation, validate the new software and complete the commit step:

install commit

The deciding evidence is the actual show install summary state, not an assumption based on the last command entered.

Post-Upgrade Cleanup

Immediately after the upgrade, the switch had approximately 300 MB of free flash space. After the new release was verified, inactive installation files were removed:

install remove inactive

After cleanup, free space increased to approximately 1.2 GB.

This command can remove unused package files and BIN images. Always review the proposed deletion list before confirming it. Cleanup should follow successful version, boot-variable, install-state, and operational validation rather than being treated as the first response to every install error.

Practical Troubleshooting Workflow

  1. Confirm the current IOS XE version, boot mode, boot variable, and committed state.
  2. Check flash contents and available space.
  3. Verify the target image file and its hash.
  4. Review inactive-file cleanup output before approving deletion.
  5. Run the standard one-shot install command when the image has not already been added.
  6. If Super package already added appears, stop repeating the Add operation.
  7. Use show install summary, show install inactive, and show install log to identify the current stage.
  8. Activate only when the package has already been added and the observed state supports that action.
  9. After reload, verify the running version, Install mode, packages.conf, and operational health.
  10. Run install commit, then verify state C and confirm that the auto-abort timer is inactive.
  11. Remove inactive files only after the new release is confirmed stable.

Key Takeaway

The most important lesson from this upgrade was that Super package already added was a state message, not proof of a damaged image.

The safe response was:

stop repeating Add
→ inspect the install state
→ continue from the completed stage
→ verify the new release after reload
→ install commit and verify C
→ clean up only after validation

The switch successfully upgraded from IOS XE 17.9.4a to 17.18.4. The recovery decision was based on the package state already present on the switch. The new release was explicitly committed, and the final committed status was verified rather than assumed.

References

Note: This article is based on an actual maintenance record. Device-identifying information and internal network details have been removed. Commands that activate software, reload the switch, or delete inactive files can interrupt service or remove rollback files. Verify the exact platform, release notes, image, package state, and maintenance plan before using them.

Comments

Post a Comment

Popular posts from this blog

Cisco Nexus Syslog Not Reaching NMS: Troubleshooting VRF, mgmt0, and Severity

During a routine configuration review in a newly assigned network environment, I noticed that syslog messages from a Cisco Nexus switch were not appearing on the NMS. The switch itself was reachable through the management network, so the basic management path initially appeared to be working. However, when I checked the remote syslog configuration, I found an inconsistency between the management routing path and the VRF used by the syslog servers. This became the starting point of the troubleshooting process. Environment The device was a Cisco Nexus 9000 Series switch using the dedicated management interface for out-of-band management. Management interface: mgmt0 Management routing: management VRF Remote syslog transport: UDP 514 Remote syslog severity: notifications Remote syslog facility: local7 NTP was also configured through the same management interface and management VRF, and NTP communication was working normally. ntp server <NTP-SERVER-IP...
Read more

Cisco Nexus show logging server Explained: Status, Severity, Facility, VRF, and Port

When troubleshooting remote syslog on a Cisco Nexus switch, one of the most useful commands is: show logging server The command provides a quick view of how each remote syslog server is configured and whether the switch has detected any transmission problem. This article explains the main fields you should check and how to interpret them during troubleshooting. Why show logging server Is Useful A remote syslog configuration can look correct in the running configuration while still using the wrong VRF, severity level, facility, or destination. The show logging server command makes these values easier to verify in one place. The most useful fields are: Server status Server severity Server facility Server VRF Server port Server Status Cisco NX-OS can display different states for a configured remote syslog server. Cisco documents the following states: Configured - The syslog server configuration was accepted. No errors found - Syslog...
Read more