Kali "E: Unable to Locate Package": The Sources File, the Cache and the Name

The package almost always exists — "E: Unable to locate package" is Kali telling you it has never successfully talked to a working repository, not that the software is missing. The fix is almost always one of three things: you never ran sudo apt update after installing, your sources file is empty or pointed at the wrong branch, or (since Kali 2026.2) an old sources.list you edited months ago is now fighting with the new sources file Kali actually reads. Here's the part that surprises people: reinstalling Kali fixes this every time, which is exactly why so many guides tell you to nuke and reinstall — but it's treating the symptom, not the cause, and the same three-line fix works without losing anything on your drive.

Jake had a customer's laptop open on the bench, trying to get a data-recovery tool onto his Kali WSL install before a 2pm pickup. Every sudo apt install came back with the same red line: E: Unable to locate package. He tried three different spellings. He tried the exact command from a five-year-old YouTube video. Nothing. By 1:45 he was googling "reinstall Kali Linux" and mentally writing off the appointment.

He didn't need to reinstall anything. He needed one command he'd never run, and about four minutes to understand why apt was lying to him about a package that was sitting right there in the repository the whole time.

The one question that tells you which fix you need

Before you touch anything else, run this and actually read what it prints:

1. Open a terminal (Ctrl+Alt+T on Xfce, or click the Terminal icon).
2. Run sudo apt update and let it finish completely.
3. Look at the last few lines. Did it end cleanly, with something like "Reading package lists... Done" and no red text, or did it print errors in red?
4. If it ended cleanly, run sudo apt install <package-name> again and see if the error is still there.

That single check splits every reader into one of two groups, and they need completely different fixes. Group one: apt update finishes clean, but the specific package still won't install — that's almost always a name problem, not a system problem. Group two: apt update itself throws errors — that's a sources or key problem, and installing anything is pointless until it's solved.

apt update runs clean, but the package still isn't found

If update finished without errors, apt genuinely has a current package list — and it still can't find what you typed. That narrows things fast.

Check the spelling before anything else

This sounds obvious, and it's still the single most common cause. Package names on Kali are case-sensitive, use hyphens (never underscores), and don't include version numbers. There's no autocorrect on a command line — Kali will not guess that docker means docker.io, or that nmapp means nmap. Type the first four or five letters and press Tab; if apt's bash completion offers nothing, you've probably got the wrong first letters, not a broken system.

If you're not sure the name exists at all, search for it instead of guessing:

apt-cache search partial-name
apt search partial-name

Both commands search the descriptions apt already downloaded — no fresh network call needed — and they'll usually surface the real name if you had it slightly wrong.

The package may have been renamed or folded into another one

Kali is a rolling distribution — tools get renamed, merged, or replaced constantly as upstream projects change. If a tutorial from a couple of years back names a package that no longer exists, that's not your system being broken; it's the tutorial being out of date. Search for the tool's current name on the Kali package tracker (pkg.kali.org) before assuming the fix is on your end.

You're on the wrong branch or missing a component

Kali's default sources file enables the kali-rolling branch and the main contrib non-free non-free-firmware components. If you (or a script you ran) switched to kali-last-snapshot, or if the non-free component got stripped out at some point, packages that depend on non-free bits — some firmware and wireless tools, for example — simply won't resolve. Check which branch you're actually on:

grep -i suite /etc/apt/sources.list.d/kali.sources

It should say kali-rolling. If it says anything else, or the file doesn't exist at all, keep reading — that's the next section.

Your sources file is empty, wrong, or fighting an older one

This is genuinely the newest wrinkle behind this error, and it's why old guides that tell you to "just re-add the kali-rolling line to sources.list" can now leave you worse off than before, on a machine that was set up after mid-2026. If your Kali install already has a working kali.sources file and you then paste in an old one-line entry to sources.list because a five-year-old tutorial told you to, apt now has two sources describing the same repository, sometimes with mismatched components — and depending on how they conflict, apt can start ignoring one of them silently, or throw a "duplicate source" warning you glossed over.

First, find out what you're actually running:

cat /etc/apt/sources.list.d/kali.sources 2>/dev/null
grep -v '^#' /etc/apt/sources.list 2>/dev/null

You want exactly one of these two to contain a real, populated entry — not both half-filled, not both empty.

Rebuilding the modern kali.sources file by hand

If kali.sources is missing, empty, or clearly wrong, replace it with the current default:

1. Back up whatever is currently there: sudo cp /etc/apt/sources.list.d/kali.sources /etc/apt/sources.list.d/kali.sources.bak (skip if the file doesn't exist yet).
2. Open it for editing: sudo nano /etc/apt/sources.list.d/kali.sources.
3. Replace the entire contents with:

   Types: deb
   URIs: http://http.kali.org/kali/
   Suites: kali-rolling
   Components: main contrib non-free non-free-firmware
   Signed-By: /usr/share/keyrings/kali-archive-keyring.gpg

4. Save (Ctrl+O, Enter, then Ctrl+X in nano) and make sure the old-style file isn't also carrying a conflicting entry — comment out or remove any active deb lines in /etc/apt/sources.list if you're keeping kali.sources as the source of truth.
5. Run sudo apt update and confirm it finishes without errors.

The URIs value points at Kali's load balancer, which redirects you to a healthy mirror automatically — don't hardcode a specific geographic mirror unless a specific one is documented as required for your setup, because mirrors move and retire and a hardcoded one will eventually start silently failing again.

apt update fails with a key or signature error

If the output from apt update mentions NO_PUBKEY, or shows an error from a sub-process called sqv, that's a different problem wearing the same costume. It's not that the repository is unreachable — it's that apt can reach it but refuses to trust what it downloaded, because the signing key it's checking against is missing or has expired. Kali verifies repository metadata with Sequoia-PGP (sqv), and its keys are periodically re-extended, so this can happen even on a system that's been working fine for months.

We've covered this exact error, including the current archive key fingerprint and the full fetch-and-verify walkthrough, in a dedicated post: fixing the missing Kali signing key error. The short version, if you just want the command: fetch a fresh keyring with wget, save it to /usr/share/keyrings/kali-archive-keyring.gpg, then run apt update again. Don't work around this by disabling signature checks — that removes the one thing standing between you and a tampered package mirror, and it's never the right fix even when it's the fast one.

Fixing broken or held packages that block new installs

Sometimes "unable to locate package" isn't the whole error — it's one line in a longer wall of text that also mentions unmet dependencies, held broken packages, or a package stuck partially configured from an earlier interrupted install (a closed lid mid-upgrade, a killed terminal, a power cut). apt gets defensive when that happens: it won't let you install anything new until the mess is cleared.

Work through these in order — cheapest first, most drastic last:

1. Finish any half-configured installs. sudo dpkg --configure -a — this resumes any package that got interrupted mid-setup.
2. Let apt repair dependencies. sudo apt --fix-broken install (older docs write this as apt-get install -f — same effect). This installs whatever's missing to satisfy dependencies apt already knows about.
3. Clear the download cache and refresh. sudo apt clean then sudo apt update again — this discards any corrupted downloaded .deb files that might be causing the same failure on every retry.
4. Find the specific broken package by name. dpkg -l | grep ^..r lists anything dpkg has flagged as needing reinstallation. Note the exact name.
5. Reinstall it cleanly, or remove it as a last resort. Try sudo apt install --reinstall <package-name> first. Only if that also fails should you force a removal with sudo dpkg --remove --force-remove-reinstreq <package-name>, then reinstall it fresh afterward.

"I just want every Kali tool installed" — the metapackages

A lot of readers land on this error while trying to install "all of Kali" and typing something that isn't actually a real package name. There's no single package literally called "everything" that you'd guess by accident — but there is a real metapackage system built exactly for this, and it's worth knowing the names precisely.

Each of these depends on the one above it, so you don't need to install more than one — installing kali-linux-everything pulls in kali-linux-large and kali-linux-default automatically. Before running any of them, update and upgrade first, since installing a huge metapackage on top of a stale package list is asking for the exact broken-dependency mess covered above:

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y kali-linux-everything

Specifically stuck on kali-win-kex? Read this first

If the exact command that's failing is sudo apt install kali-win-kex, the everything above still applies — check apt update output first, fix sources or keys if that's the issue — but there's one more thing worth ruling out. Win-KeX is the tool that gives Kali a graphical desktop when it's running inside Windows Subsystem for Linux; the package name is exactly kali-win-kex, all lowercase, hyphenated. If you've typed win-kex without the kali- prefix, or winkex as one word, apt will report it as not found even with a perfectly healthy repository.

It's also worth being clear about where this package is meant to run. It's built for a genuine WSL 2 Kali install — the one you get from the Microsoft Store — not a Kali live USB, not a plain VirtualBox or VMware VM, and not a bare-metal install. It will attempt to install on those too if your sources are working, but it has nothing to attach a Windows session to outside WSL, so it won't do anything useful there. If you're trying to get a Kali desktop on Windows without WSL at all, that's a different, larger topic than a package name typo — a VM with its own desktop environment is the more direct route.

sudo apt update
sudo apt install -y kali-win-kex

apt update runs, but nothing actually downloads

A different failure mode: the command runs, doesn't error, but hangs on "Connecting to http.kali.org" for a long time, or completes with 0 bytes fetched. This one is rarely apt's fault at all.

Check the connection itself

Confirm you have working internet from the same machine, separately from apt:

ping -c 4 http.kali.org

If that fails outright, the problem is DNS, a VPN, a captive portal you haven't accepted, or (on WSL) a Windows-side firewall or VPN client that isn't passing traffic through to the Linux subsystem. Fix the network first; nothing apt-side will help until basic connectivity works.

A single mirror having a bad day

The load balancer at http.kali.org is supposed to route you to a healthy mirror automatically, but individual mirrors do occasionally go down or lag. If ping works fine but apt itself is what's stalling, retry after a few minutes rather than immediately assuming your configuration is wrong — this genuinely is a "wait it out" situation sometimes, and it's the one failure mode on this page that isn't really something you broke.

Editing your sources safely, without making it worse

A recurring pattern in older guides is telling readers to paste extra deb lines pointing at very old Kali branches (names like "sana" or "moto") to unlock a package that's since disappeared from the current branch. That advice is wrong for a current system, and it's worth saying plainly: mixing archived, unsupported branches into a live rolling install is how you get version conflicts that are much harder to untangle than the original missing-package error. Kali's rolling branch is meant to be self-contained — if a package genuinely no longer exists on kali-rolling, the fix is finding its replacement, not resurrecting a repository from years ago.

Similarly, don't add unrelated Debian or Ubuntu repositories to pull in a package Kali doesn't ship. Kali tracks Debian testing closely but isn't binary-compatible with arbitrary Debian or Ubuntu packages; mixing them is one of the fastest ways to end up with the exact broken-dependency chain covered earlier, on packages that used to work fine.

What "unable to locate package" does not mean

It does not mean your internet is generally broken — you can browse the web fine on the same machine while apt has no working repository, because the two use different configuration entirely. It does not mean Kali is corrupted, and it does not mean you need to reinstall. And it doesn't mean the developers removed the tool out of spite; Kali's package set changes constantly as a rolling distribution, and a rename is far more common than a genuine removal. The error is apt being precise about one narrow fact: given what it currently knows, that exact string isn't an installable package name. Everything upstream of that — why apt "knows" what it knows — is what the sections above walk through.

When none of this works

If you've confirmed the spelling, confirmed the branch, rebuilt kali.sources from scratch, fixed the signing key, and cleared broken packages, and apt update still won't complete cleanly, the honest answer is that something on that specific system is genuinely damaged in a way generic troubleshooting can't reach from a browser tab — a corrupted dpkg status database, disk errors, or a WSL instance with a broken filesystem layer are all possible at that point. At that stage, the Kali Forums (linked from kali.org/docs) are worth posting to with the exact text of your apt update output; a system-specific corruption needs someone looking at your actual error, not a general guide. If you don't have the patience for that and the install is disposable (a fresh WSL instance, a throwaway VM), reinstalling that instance is a legitimate last resort — just know it's a last resort, not the first thing to reach for.

Frequently asked questions

What does "E: Unable to locate package" actually mean?

It means that, based on the package lists apt currently has stored locally, no package matches the exact name you typed. It says nothing about whether the software exists in Kali's repository generally — only about what apt's local, possibly outdated, copy of that repository's index contains.

Why do I get this error right after a fresh Kali install?

Fresh installs, minimal images, and new WSL instances often have an outdated or empty local package index until you run sudo apt update for the first time. Skipping that step is the single most common cause of this error on brand-new systems.

Is my package name just misspelled?

It's worth checking before anything else. Package names are lowercase, hyphenated, and don't include version numbers. Use apt search partial-name to find the exact current name rather than guessing.

Why can't apt find kali-win-kex specifically?

Usually a typo in the name itself (it's exactly kali-win-kex, with that prefix and those hyphens), or the same update/sources issue affecting every other package on that system. Confirm apt update finishes clean first.

Do I need to install Win-KeX inside WSL or on the Kali VM/bare metal?

Win-KeX is built for a genuine WSL 2 Kali installation. It will install on a VM or bare-metal Kali if your repositories are working, but it has nothing to connect to on those setups, so it won't provide a usable desktop there.

How do I install every tool in Kali at once?

Update and upgrade first, then install the kali-linux-everything metapackage, which depends on every other tool metapackage Kali offers.

What's the difference between kali-linux-default, kali-linux-large, and kali-linux-everything?

Each one is a superset of the one before it: default matches the standard desktop image, large adds a wider tool selection, and everything includes every metapackage and tool Kali maintains. Installing the largest one you need automatically pulls in the smaller ones.

Why does apt update fail with a GPG/key error?

Kali verifies repository data against a signing key, and that key is periodically re-extended. If your local keyring is missing the current key or holds an expired one, apt refuses to trust the downloaded metadata and reports a signature error instead of updating.

My kali.sources file looks fine — why is it still not working?

Check whether the older sources.list file also has an active, conflicting entry. Having both files describe the same repository with mismatched details is a common cause of apt behaving inconsistently even when each file looks correct on its own.

What happened to /etc/apt/sources.list in Kali 2026.2?

Kali 2026.2 introduced a new deb822-style file, /etc/apt/sources.list.d/kali.sources, as the default location for repository configuration on fresh installs. Existing systems were not automatically converted and keep using the older one-line sources.list; both formats work, but they shouldn't both be actively defining the same repository at once.

How do I fix broken or held packages blocking a new install?

Work through dpkg --configure -a, then apt --fix-broken install, then apt clean followed by apt update, checking after each step. Only force-remove a specific package as a last resort, and reinstall it afterward.

apt update runs but nothing downloads — why?

This is usually a network issue rather than an apt configuration problem: no real internet connectivity, a VPN or firewall blocking traffic, or (on WSL) a Windows-side network setting not passing through. Confirm basic connectivity with ping before touching sources files.

Can a bad mirror cause "unable to locate package"?

Indirectly, yes — if a mirror is unreachable, apt update can fail to complete, leaving your local package index stale or incomplete, which then produces this exact error on install. Kali's default load balancer routes around unhealthy mirrors automatically in most cases; retrying after a short wait is a reasonable first step.

Should I add extra repositories (Debian, Ubuntu PPAs) to fix this?

No. Kali isn't binary-compatible with arbitrary Debian or Ubuntu packages, and mixing sources like this is a common cause of the broken-dependency problems covered above, not a reliable fix for a missing package.

I fixed the sources file and it's still broken. What now?

Run dpkg --configure -a and apt --fix-broken install to rule out a broken package unrelated to the sources file itself. If apt update still fails after that, the issue is likely specific to that system (corrupted dpkg database, disk problems) and is worth raising on the Kali Forums with your exact error text.

Will switching from kali-rolling to kali-last-snapshot help?

Only if you specifically need a frozen baseline for reproducibility. For everyday use, kali-rolling is the actively maintained branch, and switching away from it will not fix a missing-package error caused by sources or key configuration.

Revision note. Written September 2026, covering Kali Linux 2026.2 (kali-rolling), including the deb822 sources.list.d/kali.sources migration and the current kali-win-kex package. This will need a revisit once the next quarterly Kali release lands or the archive signing key is re-extended again. If you're staring at this error with a deadline like Jake's, take a breath — it's almost never as broken as it looks, and you're closer to fixed than you think.