CiscoSE
Wireless (Wi-Fi 7 / Catalyst 9800)Coming soonC9800-L-F-K9

C9800-L-F-K9

Catalyst 9800-L Wireless Controller, fiber uplinks

Upgrade to IOS XE 17.18.4a fails: "Download Image/Package failed" and SELinux AVC denial

Last verified: September 2026. The fix in "Resolution (confirmed fix)" was applied successfully on a C9800-L-F-K9. Commands were checked against the 9800 SELinux configuration guide and the IOS XE install documentation.

Symptoms

  • WebUI (the controller's web interface): Administration › Software Management › Software Upgrade, Upgrade Mode INSTALL, Transport Type My Desktop, File System bootflash. The upload bar turns red with "Upload failed" and Status shows "Download Image/Package failed".
  • Copying the image with SCP (Secure Copy Protocol) also fails.
  • Syslog shows an SELinux (Security-Enhanced Linux) AVC (Access Vector Cache) denial:
%SELINUX-1-VIOLATION: Chassis 1 R0/0: audispd: type=AVC msg=audit(...): avc: denied { read write } for pid=... comm="webui_upgrade_h" path="/bootflash/C9800L-wlc-universalk9.17.18.04a.SPA.bin" dev="sda1" ... scontext=system_u:system_r:polaris_nginx_webui_install_t:s0 tcontext=system_u:object_r:polaris_disk_bootflash_t:s0 tclass=file permissive=0

How to read the log

FieldMeaning
comm="webui_upgrade_h"The WebUI upgrade handler is the process that was blocked.
denied { read write } on path=/bootflash/...That process tried to open a file in bootflash for read/write and was not allowed to.
scontext ... polaris_nginx_webui_install_t / tcontext ... polaris_disk_bootflash_tThe security labels of the process (source) and the file (target). The policy does not let this process read/write a file with this label.
permissive=0SELinux is in Enforcing mode (the default on the 9800), so the action was blocked, not only logged.

Don't leave SELinux in Permissive mode. The confirmed fix below switches SELinux to Permissive only for the cleanup, then back to Enforcing. If the denial comes back after that, open a TAC (Technical Assistance Center) case (see Step 7).

Resolution (confirmed fix)

Fix applied successfully on this controller: clear the stale install state left by the earlier failed attempt while SELinux is temporarily in Permissive mode, then retry the install.

Read before you start. service internal unlocks hidden internal commands. Permissive mode stops SELinux from blocking anything; violations are only logged. Do this in a maintenance window, preferably under TAC guidance, and always finish step 5. Plan for the controller to reload.

1. Enable internal commands (required by the SELinux and clear-install commands)

configure terminal
service internal
end

2. Put SELinux in Permissive mode temporarily, then save

set platform software selinux permissive
write memory

Confirm with show platform software selinux (mode: Permissive).

3. Clear the stale install state

clear install state

On this controller, the WLC (Wireless LAN Controller) reloaded after this step. Wait for it to come back, then run show install summary to confirm no install operation is pending.

4. Retry the installation. Use the CLI (command-line interface) procedure in Steps 3–6 below: copy the image, verify its MD5 checksum, then run install add file ... activate commit. If what failed was an APSP (AP Service Package), retry the APSP install instead.

5. Restore SELinux Enforcing mode and remove internal-command access, then save

set platform software selinux enforcing
configure terminal
no service internal
end
write memory

Keep this order: set platform software selinux only works while service internal is still enabled.

Verify the controller is back to its secure state:

  • show platform software selinux shows Enforcing.
  • show running-config | include service internal returns nothing.
  • show platform software audit summary shows no new AVC denials.

The global-configuration equivalent for the SELinux mode is platform security selinux {enforcing | permissive}.

If the fix above doesn't apply: other causes to rule out

  1. Wrong or mismatched image file. The file in the log (C9800L-wlc-universalk9...) follows a different naming pattern from the C9800-L image the WebUI shows (C9800-L-universalk9_wlc...). In 17.18.x, the -wlc-universalk9 pattern is what the CW9800 controllers use (CW9800H, CW9800M and CW9800L). A CW9800L image is not the same as a C9800-L image. Inference: confirm the exact filename and checksum against software.cisco.com before doing anything else.
  2. Stale or partial file in bootflash from an earlier WebUI or SCP attempt, which the WebUI upgrade handler is then denied access to. Confirmed on this controller as a stale install state; see Resolution above.
  3. WebUI image-size limitation. Documented in the 17.18.4a release notes: when upgrading from 17.9.5 or lower, or 17.12.2 or lower, to 17.18.2 or higher, the WebUI does not support images larger than 1.5 GB. Use the CLI (command-line interface) instead, or step through an intermediate release.
  4. SCP not set up correctly on the controller or the server (see Step 4).

Step 0: Record the current state

show version | include IOS XE|uptime|Installation mode
show install summary
dir bootflash: | include 17.18|.bin|.pkg|.conf
  • Note the current release. That tells you whether cause 3 applies and whether you can upgrade directly.
  • Direct upgrade to 17.18.4a is supported from 17.3.4c or later, 17.4.x–17.17.x, and 17.9.6 or later. Older releases need an intermediate step.
  • If show install summary shows an operation in progress or uncommitted, try install abort first. If that doesn't clear it, or the SELinux denial persists, use the Resolution (confirmed fix) procedure above.

Step 1: Confirm you downloaded the correct image

  • Download from software.cisco.com under Catalyst 9800-L Wireless Controller, not CW9800L.
  • Use the filename exactly as it appears on the download page. The WebUI for this controller showed C9800-L-universalk9_wlc.17.18.04a.SPA.bin.
  • Note the MD5 and SHA512 checksums listed on the download page.
  • Do not rename the file.

Step 2: Remove stale files

delete /force bootflash:<stale-or-wrong-image>.bin
install remove inactive

install remove inactive is the same action as Remove Inactive Files in the WebUI. Confirm the prompt it shows.

Step 3: Copy the image from the CLI (not the WebUI)

Pull the image from a server the controller can reach. FTP, HTTP(S) and SCP all work. For roughly 1 GB images, avoid TFTP: many TFTP servers fail on large files.

copy ftp://<user>:<password>@<server>/<exact-image-name>.bin bootflash:
copy http://<server>/<exact-image-name>.bin bootflash:
copy scp://<user>@<server>/<exact-image-name>.bin bootflash:

Step 4: If SCP fails, check the prerequisites

SCP rides on SSH (Secure Shell). The controller needs:

  • An RSA key pair and working SSH.
  • AAA (Authentication, Authorization and Accounting) with exec authorization.
  • A user with privilege level 15. With a lower privilege level, the connection closes.

Only if you are pushing the file to the controller from a laptop or server. The block below is Cisco's local-AAA example.

Production controllers almost always have AAA already configured (TACACS+/RADIUS). Don't paste aaa new-model or the aaa ... default local lines over an existing AAA setup, because you can lock yourself out. On a production controller, add only ip scp server enable, and confirm that your user has exec authorization and privilege 15.

ip scp server enable
aaa new-model
aaa authentication login default local
aaa authorization exec default local
username <user> privilege 15 secret <password>
ip ssh bulk-mode        ! optional, speeds up large transfers

Then send it from the workstation to <user>@<wlc-ip>:bootflash:<exact-image-name>.bin.

Step 5: Verify the file before installing

verify /md5 bootflash:<exact-image-name>.bin

The hash must match the MD5 on software.cisco.com. If it doesn't, delete the file and copy it again. Never install an image that fails this check.

Step 6: Check the APs, then install

Before activating:

  • Review FN74383. Access points (APs) that are running, or have ever run, 17.12.4, 17.12.5, 17.12.6 or 17.12.6a can run out of flash space, which prevents their upgrade. Complete the actions in that field notice first.
  • If you plan to use ISSU (In-Service Software Upgrade) on an HA (high availability) pair, review defect CSCwv81329 first. It doesn't apply to a standalone controller.

Install:

install add file bootflash:<exact-image-name>.bin activate commit

This reloads the controller and every AP joined to it goes down until it rejoins and upgrades. Do it in a maintenance window.

After the reload: show version, show install summary and show ap summary confirm the new release is running and committed and that the APs have rejoined.

Step 7: If the AVC denial comes back with a verified, correctly named image

At that point, treat it as a platform defect rather than a process error. Open a Cisco TAC case with:

  • The exact %SELINUX-1-VIOLATION syslog line
  • show tech-support (or show tech wireless)
  • show platform software selinux
  • show platform software audit summary
  • show platform software audit all
  • A btrace archive: request platform software trace archive

Known issues to watch after upgrading to 17.18.4a

  • A community report describes an SNMP (Simple Network Management Protocol) defect after upgrading to 17.18.4a (secondary source, not in the release notes). Validate SNMP polling after the upgrade.

References