Troubleshoot normal install-mode upgrade issues

Guides you through troubleshooting normal INSTALL-mode upgrade issues, including resolving super package conditions, handling add or activate failures, addressing uncommitted or inconsistent install states, and performing rollbacks after commit.

Procedure

Resolve a scenario which states that super package has been already added.
1. Identify the target image that has been added already.
  Example:
```
switch# install add file flash:<IMAGE.bin> activate commit
FAILED: install_add_activate_commit : Super package already added.
Add operation not allowed. 'install remove inactive' can be used
to discard added packages
```
2. Confirm the inactive target image.
  Example:
```
switch# show install summary
Type  St   Filename/Version
--------------------------------
IMG   C    <CURRENT_RELEASE>
IMG   I    <TARGET_RELEASE>
--------------------------------
Auto abort timer: inactive
```
  I state means that the target image has already been added and expanded, but it is not active.
3. Verify the inactive package.
  Example:
```
switch# show install inactive
IMG   I    <TARGET_RELEASE>
```
  Confirm that the inactive target is the intended, hash-verified release.
4. Activate the staged package
  Example:
```
switch# install activate
...
Activate: Passed on [1]
SUCCESS: install_activate
```
5. Confirm the uncommitted target state.
  Example:
```
switch# show install summary
IMG   U    <TARGET_RELEASE>
Auto abort timer: active on install_activate,
time before rollback - 01:58:40
```
  Validate the target while it is uncommitted. Commit it only if the post-upgrade checks pass; otherwise use the supported abort method.
6. Commit the validated target image.
  Example:
```
switch# install commit
...
Commit: Passed on [1]
SUCCESS: install_commit
```
  Commit makes the validated target persistent.
Follow these guidelines:
- Preserve show install log. If the staged target is the exact verified image that you still intend to run, continue the supported three-step upgrade workflow instead of adding it again.
- If you are abandoning or re-staging the inactive target and no required rollback package must be retained, run the install remove inactive command, review the proposed deletions, and retry the approved one-step workflow. Do not rerun the add command or do not run clear install state command.
Analyse image add or activate operation failure.
1. Identify the failed install phase.
  Example:
```
switch# install add file flash:<IMAGE.bin> activate commit
install_add_activate_commit: START
...
Add: Passed on [1]
Activate: Failed on [1]
FAILED: install_add_activate_commit <FAILURE_REASON>
```
  In this example, the image add operation succeeded, but activation failed. The target can remain staged or the install state can be incomplete.
2. Review the current install state.
  Example:
```
switch# show install summary

>>> <CURRENT AND TARGET STATES>
```
  The output displays the current and target states.
3. Preserve and review the install log.
  Example:
```
switch# show install log
[<OPERATION_ID>|install_add]: END SUCCESS flash:<IMAGE.bin>
[<OPERATION_ID>|install_activate]: END FAILURE <FAILURE_REASON>
```
  The install log identifies the failed phase. Preserve the log before attempting any cleanup or retry activity.
Check the exact error, image-platform compatibility, member state, space, boot mode, and any earlier uncommitted operation. If the supported abort operation or inactive image cleanup operation does not restore a clear state, contact Cisco Support.
Resolve an activation that succeeded but was not committed.
1. Confirm the uncommitted target state.
  Example:
```
switch# show install summary
Type  St   Filename/Version
--------------------------------
IMG   U    <TARGET_RELEASE>
--------------------------------
Auto abort timer: active on install_activate,
time before rollback - 01:52:08
```
  The U state means that the target is running but not persistent.
  
  The active timer protects the switch by returning it to the prior committed image if validation or commit does not finish.
2. Commit the running target image if all post-upgrade checks pass.
  Example:
```
switch# install commit
install_commit: START
Commit: Passed on [1]
SUCCESS: install_commit
```
  Commit operation makes the running image persistent and stops the automatic rollback timer.
3. Abort the uncommitted target if the new release is unhealthy and it has not been committed.
  Example:
```
switch# install abort
This operation may require a reload of the system.
Do you want to proceed? [y/n] y
...
SUCCESS: install_abort
```
  Abort operation returns the installation to its prior state and allows you to reload the switch. Keep console access throughout the operation.
Do not routinely stop the auto-abort timer; it is an important recovery safeguard.

Perform commit action only after the new release and services are validated.
Resolve an active or inconsistent install state.
1. Review the unexpected install state.
  Example:
```
switch# show install summary

>>> <UNEXPECTED I, U, OR D STATE>
```
  Identify the displayed install state—UNEXPECTED, I, U, or D.
2. Preserve and review the failed transaction log.
  Example:
```
switch# show install log

>>> <LAST OPERATION DID NOT REACH A SUCCESSFUL END STATE>
```
  The log indicates that the last operation did not reach a successful end state. The previous transaction is incomplete. Starting another upgrade in this case can make device recovery harder.
Use only the abort, commit, rollback, or cleanup action supported for the displayed state and exact release. If those supported actions fail, then collect the required diagnostic data and contact Cisco Support.

Note

The clear install state is not a normal cleanup command; it can remove provisioned SMUs and rollback points and can reload the switch or stack.
Perform a roll back action after commit action.
1. List available rollback points.
  Example:
```
switch# show install rollback
ID    Label          Description
----------------------------------------
2     No Label       No Description
1     <KNOWN_GOOD>   <PREVIOUS_RELEASE>
```
  This step confirms that the required saved rollback point exists.
2. Inspect the intended rollback ID.
  Example:
```
switch# show install rollback id 1
Rollback id - 1
Type  St   Filename/Version
--------------------------------
IMG   C    <PREVIOUS_RELEASE>
```
  Confirm the exact rollback ID, release, and retained files before proceeding.
3. Roll back to the selected rollback ID.
  Example:
```
switch# install rollback to id 1
install_rollback: START
...
SUCCESS: install_rollback
```
  A rollback action is disruptive and can reload the system. Validate the exact path and expected impact in the platform release notes.
Do not remove inactive files until the rollback decision is complete. If the requested rollback point is absent, use an approved normal install or downgrade procedure only when that path is supported.

Procedure

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Example: