Installed C9800-40 bin file to C9800-CL in error. Need fix to upgrade.

[colossus1611]

Hi All,

We accidentally used the C9800-40 17.12.5.bin file on C9800-CL model in Install mode. While the package got created, the upgrade failed for obvious reasons. We copied the right image once we realised our mistake, but now it doesn't let us create the package and gives the below error:

WLC04#install add file bootflash:C9800-CL-universalk9.17.12.05.SPA.bin
install_add: START Fri May 09 20:05:30 ST 2025
install_add: Adding IMG
[1] Chassis 1/R0 FAILED: Super package already added. Add operation not allowed. install remove inactive can be used to discard added packages
[2] Chassis 2/R0 FAILED: Super package already added. Add operation not allowed. install remove inactive can be used to discard added packages
FAILED: install_add /bootflash/C9800-CL-universalk9.17.12.05.SPA.bin

How do we fix this to install and activate the right image? 

We have already tried install remove inactive but it did not help.

Also, we predownloaded the incorrect image as well so I hope that once we activate the right image, we should be able to predownload that again and overwrite the incorrect one on APs too.

[marce1000]

- Erase the controller with : write erase

  And start the installation process again,

 M

[Rich R]

How could you have predownloaded if the add failed @colossus1611 ? You can only predownload after the add is done!

The AP images are independent of the WLC so if you really predownloaded the AP 17.12.5 software then that's already correct - the AP images will be the same either way.

As for fixing your install situation:
1. Try install remove file bootflash:C9800-CL-universalk9.17.12.05.SPA.bin
2. If that doesn't work you have to use the nuclear option which will reload the controller:

9800#conf t
Enter configuration commands, one per line. End with CNTL/Z.
9800(config)#service internal
9800(config)#end
9800#clear install state
clear_install_state: START Fri Oct 27 09:50:03 BST 2023

This command will remove all the provisioned SMUs, and rollback points. Use this command with caution.
A reload is required for this process. Press y to continue [y/n]y
--- Starting clear_install_state ---
Performing clear_install_state on all members
[1] clear_install_state package(s) on chassis 1/R0
[1] Finished clear_install_state on chassis 1/R0
Checking status of clear_install_state on [1/R0]
clear_install_state: Passed on [1/R0]
Finished clear_install_state

Send model notification for before reload
Install will reload the system now!
Requesting RP pvp reload

When the controller comes back it should have wiped the corrupted install database.

[Scott Fella]

If it was me, I would just rebuild the VM.  Since its a VM, it doesn't take long to stand a new one up and then restore your configuration to the new VM.  This way you can start fresh.  You probably should standup a dev/test VM also so you can do all the pre-work and testing prior to doing anything in production.

[colossus1611]

The APs predownload was done after we ran the install add file command without using activate at the end. We then did the predownload which means APs have got the 17.12.5 image for C9800-40 controller rather than the C9800-CL controller, isn't it?

It's a Production device with hundreds of APs, so I can't just break things and rebuild.

Just to make it clear again, the WLC is C9800-CL and we have incorrectly packaged the C9800-40 17.12.5 file, which then did not work obviously when we used the activate command. 

Below are the steps we originally did using the incorrect IOS from C9800-40.

1. Add the Image: Use the install add file command to add the image to the controller's software inventory. 
2. Predownload to Access Points (Optional):
   • To predownload to all access points, use ap image predownload. 
   • To predownload to a specific AP, use ap name <ap-name> image predownload.
3. Activate the New Image: Use install activate to activate the new image and prepare for the upgrade. 

We have a secondary controller that is upgraded to using the correct firmware of C9800-CL to version 17.12.05. Should I migrate the APs to that controller first and try fix the Primary controller then?

Is there a non-disruptive way to fix the Primary controller?

[marce1000]

 - @colossus1611  >...Should I migrate the APs to that controller first and try fix the Primary controller then?
                                   Yes

                              >....Is there a non-disruptive way to fix the Primary controller?
                                   No,

   M.

[Saikat Nandy]

Can you please put the output of these two commands in a notepad and share - 

show install summary

show ap image

[colossus1611]

Attached is the output for show install summary and show ap image as requested.

[Rich R]

WLC04#show install summary
[ Chassis 1/R0 2/R0 ] Installed Package(s) Information:
State (St): I - Inactive, U - Activated & Uncommitted,
C - Activated & Committed, D - Deactivated & Uncommitted
--------------------------------------------------------------------------------
Type St Filename/Version
--------------------------------------------------------------------------------
IMG U 17.12.03.0.3740
--------------------------------------------------------------------------------
Auto abort timer: inactive
--------------------------------------------------------------------------------

Well based on that I'd say your install database is probably corrupted.
You can try the install remove I suggested on my previous reply but I doubt that it's going to work, so then you are left with the nuclear option to clear the install database.

Most of the APs already have the 17.12.5 image so they won't need another pre-download.  There are a few APs which still need the pre-download.  If they failed before then they probably need to be reloaded before attempting again (multiple well known bugs with APs running out of memory and /tmp space)

[Scott Fella · Accepted solution]

---

We have a secondary controller that is upgraded to using the correct firmware of C9800-CL to version 17.12.05. Should I migrate the APs to that controller first and try fix the Primary controller then?

Is there a non-disruptive way to fix the Primary controller?

---

Your environment is already degraded.  The purpose of a secondary or tertiary is to have the ability to move ap's to them so you can remediate any failures or even if one of the controllers failed.  There is no question that you should move the ap's to the secondary, this should of been done once the primary had issues after the failed upgrade.  If you don't trust your secondary, then that is a bigger issue.  Everyone with N+1 should failover to the secondary once in a while to make sure its working as expected.  

I would of moved a group of ap's to the secondary, verified that everything is working and users are not experiencing any issues. Once verified, then I would move all the other ap's to the secondary.  Rebuild the VM and then restore the config or take the secondary config, and edit it for the primary.  You must make sure your run a diff between the two if using N+1 so that you know the config are alike.  If running SSO, then you just break up the HA or just remove the primary and rebuild it, then let the new VM controller sync.  

This again is why having a test environment helps, you can figure out what works best for you. The longer the service is impaired, the worse the experience and users never forget.  

[Rich R]

> The APs predownload was done after we ran the install add file command without using activate at the end. We then did the predownload which means APs have got the 17.12.5 image for C9800-40 controller rather than the C9800-CL controller, isn't it?
Just realised the failed add you showed was when you tried to add the CL image after adding the 9800-40 image! So maybe you did pre-download 17.12.5 to the APs ok.  As I said that isn't a problem because there is only one image for the APs regardless of the WLC software package.

> It's a Production device with hundreds of APs, so I can't just break things and rebuild.
You might not have a choice ...

> We have a secondary controller that is upgraded to using the correct firmware of C9800-CL to version 17.12.05. Should I migrate the APs to that controller first and try fix the Primary controller then?
That would be sensible if you're going to need to reload the primary a few times.

> Is there a non-disruptive way to fix the Primary controller?
Possibly. As @Saikat Nandy says let's get a clear baseline of where you are right now. Provide the output from:
show install summary (we'll see what got added)
show ap image (we'll clearly see from that if the APs had the image pre-downloaded)
show ap image file summary (that will show us if it managed to add the 17.12.5 AP images)

I'm guessing we're going to see the 9800-40 17.12.5 image there in Inactive state.  So you should be able to just remove it as I suggested in my first reply except that I'd referenced the CL image not realising that that was your second attempt at adding.  So you should just be able to do the exact opposite of the original erroneous add:
install remove file bootflash:C9800-40-universalk9_wlc.17.12.05.SPA.bin

If all the tinkering since then has got the install database into a corrupted state and it doesn't allow that, then the nuclear option is your only option.  If it works, then you should be able to continue with adding the correct CL image.  No need to pre-download the APs a second time if they already have the 17.12.5 image.