Kali Rolling: “The following packages have been kept back” after apt upgrade (Why apt full-upgrade fixes it)

“Kali Rolling kept back packages after apt upgrade” is the kind of message that wastes time precisely because nothing looks broken—yet your system quietly stays half-updated. On a rolling release, that’s not cosmetic. It’s the moment your toolchain starts drifting: kernels, firmware, desktop meta-packages, or drivers stuck behind a dependency transition you didn’t approve. If you want a steadier lab foundation long-term, build around a repeatable Kali lab infrastructure instead of letting upgrades happen “whenever.”

What “kept back” means: APT’s conservative apt upgrade won’t proceed when upgrading would require changing the installed set—installing new dependencies, removing conflicts, or swapping packages during transitions. It’s the dependency resolver saying “I can’t finish this safely under your current rules.”

If you keep guessing, you lose the worst currency in ops: predictability. This post gets you back to boring upgrades—fast—using a simple simulate-first workflow (apt -s full-upgrade) so you can read the removal/install plan before anything changes, spot holds, and avoid the classic “oops, my desktop disappeared” outcome. (If you like systems that stay boring, you’ll also like a Kali pentest report template mindset: simulate, document, execute—on purpose.)

Good. Now let’s make the solver show its hand.
Then we decide—on purpose.
No roulette. No purges you’ll regret.

Why this message appears on Kali Rolling (not a “random apt bug”)

The hidden rule: apt upgrade won’t change the package set

Here’s the quiet rule that explains 90% of “kept back” drama: apt upgrade is conservative. It upgrades packages only when it can do so without adding new packages and without removing conflicting ones.

On a stable distro, that feels like a safety belt. On Kali Rolling—where packages move and dependency relationships shift—it often feels like a handbrake.

What “kept back” really means in dependency terms

“Kept back” usually translates to: “I can’t apply the upgrade you asked for unless I’m allowed to change the dependency graph.” That change might mean installing a new library, replacing one package with another, or removing something that now conflicts.

Kali’s own documentation leans into apt full-upgrade as the normal path for staying current on a rolling release, and their troubleshooting guidance repeatedly emphasizes running apt update first because it resets the solver’s view of what’s available.

The one line in APT output everyone skims—then regrets

The moment you see “kept back,” your eyes usually jump straight to the command you want to paste from a forum. The line you should actually read is the one that hints what kind of change APT needs: install something new, remove something old, or resolve a conflict.

• If APT wants to install a new dependency: upgrade may stall.
• If APT wants to remove a conflicting package: upgrade will stall.
• If a transition is mid-flight in rolling repos: stalling can be correct—for now.

The real difference: upgrade vs full-upgrade (the sentence that saves hours)

apt upgrade: safe-by-default, conservative resolver

Think of apt upgrade as a “no surprises” mode. It tries to keep your current set of installed packages intact. If upgrading Package A would require installing Package B (new dependency) or removing Package C (conflict), it often refuses.

That’s not Kali being weird. That’s APT being cautious by design.

apt full-upgrade: completes transitions by allowing removals/installations

apt full-upgrade does what upgrade does—but it’s allowed to remove currently installed packages if needed to upgrade the system as a whole. That behavior is described directly in Debian’s APT man page.

On rolling systems, that “permission to remove” is often the exact key that unlocks a stalled upgrade.

Let’s be honest… you want “safe” and “done”

I get it. You don’t want to break your machine. You also don’t want to be stuck in “kept back” purgatory for three days. The compromise is not “never use full-upgrade.” The compromise is: simulate first, then run it intentionally.

Show me the nerdy details

Under the hood, APT’s solver tries to satisfy a consistent set of package relationships: Depends, Conflicts, Breaks, Replaces. “Kept back” happens when solving requires a change that upgrade is not allowed to make. full-upgrade expands the solution space by permitting removals.

Quick diagnosis in 60 seconds (before you touch anything)

Step 1: Identify what’s held back (clean listing commands)

First: confirm what exactly is being kept back. If apt already printed the list, great—copy it somewhere. Otherwise, you can re-run a dry run to surface it.

sudo apt update
sudo apt -s upgrade
# Look for: "kept back" and the package list

Micro-habit: I keep a tiny “upgrade notes” file for rolling boxes. It’s saved me at least 30 minutes on the days I’m tired and sloppy. If you want that habit to stick, borrow patterns from a note-taking system built for pentesting (same brain, same stakes, better memory).

Step 2: See why it’s held back (dependency explanation workflow)

When a package is kept back, your goal is to answer one question: Is this blocked by a new dependency, a conflict, or a partial upgrade?

• Check policy/version candidates: apt-cache policy <package>
• See dependencies: apt-cache depends <package>
• Show reverse dependencies (what depends on it): apt-cache rdepends <package>

apt-cache policy linux-image-amd64
apt-cache depends <package-name>
apt-cache rdepends <package-name>

Step 3: Simulate the fix: apt -s full-upgrade (read the plan, not the vibes)

This is the operator move. Simulation tells you what APT would do without doing it. If you take only one thing from this post, take this:

sudo apt update
sudo apt -s full-upgrade

The single word in the simulation output that decides “go / no-go”

In the simulation output, watch for removals and ask: “Are these removals expected (like old kernels) or harmful (like your desktop meta-package)?” The word you care about is basically: Remove.

Removals aren’t automatically bad. Unreviewed removals are.

Why apt full-upgrade usually fixes it (the dependency-transition story)

Rolling repos move fast: library bumps, renamed packages, replaced dependencies

Kali Rolling inherits the pace of a rolling ecosystem: packages update frequently, libraries bump versions, and sometimes package names change. In these transitions, the “old” dependency graph and the “new” one don’t line up perfectly for a brief window.

That’s when apt upgrade throws up its hands and keeps packages back: it can’t complete the transition without changing what’s installed.

Meta-packages and transitions: why Kali is extra sensitive

Kali leans on meta-packages (collections that pull in tools) more than a typical desktop distro. That’s convenient… until a dependency changes. When a meta-package adjusts what it pulls, upgrades can require package set changes.

I once watched a lab VM “upgrade” for ten minutes and still left core tools behind—because I stubbornly ran upgrade three times. It didn’t get smarter; I just got older. (This is also why a tight shell workflow helps: a solid Zsh setup for pentesters turns “I’ll do this later” into “I can do this cleanly now.”)

Kernel, drivers, and firmware: where “kept back” becomes a time bomb

If the held-back list includes kernel images, firmware, or GPU drivers (hello, NVIDIA), it’s worth treating as time-sensitive. Not because the machine will explode—but because you’re increasing your odds of mismatched modules, weird boot behavior, or tools failing at the worst time.

The “safe full-upgrade” playbook (minimal risk, maximum progress)

Pre-flight checks: disk space, broken packages, and repo sanity

Before you run anything that can remove packages, do three fast checks:

• Disk space: upgrades fail in the dumbest ways when / is full.
• Broken package state: partial installs can poison the next run.
• Repo sanity: mixing repos is how you create chaos with confidence.

df -h
sudo apt update
sudo apt -s -o Debug::pkgProblemResolver=yes full-upgrade

Kali’s troubleshooting docs basically repeat the same theme: run apt update and fix the simple APT issues first, because a stale package list makes everything look weirder than it is.

Run it like a pro: update → simulate → execute → verify

This is the workflow I recommend when you want a low-stress outcome:

1. Update: refresh package lists.
2. Simulate: preview the full-upgrade plan.
3. Execute: run full-upgrade if the plan makes sense.
4. Verify: check what changed, reboot if needed.

sudo apt update
sudo apt -s full-upgrade
sudo apt full-upgrade
sudo apt autoremove --purge

Notice what’s missing: “panic,” “random purge command,” and “copy-paste from a 2014 forum thread.”

Post-flight verification: confirm versions, services, and reboot needs

After a full-upgrade, verify the basics before you declare victory:

• Pending upgrades: sudo apt -s upgrade should be mostly quiet.
• Broken state: sudo apt -s -f install should not propose chaos.
• Reboot hint: if kernel/libc/systemd changed, plan a reboot.

Here’s what no one tells you… the reboot you keep skipping is part of the upgrade

You can technically upgrade without rebooting. You can also technically drive with the check engine light on. If your kernel or core libraries changed, reboot soon—especially on laptops and Wi-Fi heavy setups.

Common mistakes that create “kept back” loops

Mistake #1: Running upgrade repeatedly and hoping it “eventually catches up”

I’ve done this. It’s a classic “I am very busy” move. Running upgrade again rarely changes the underlying requirement: APT still needs permission to adjust dependencies.

Mistake #2: Mixing repos or adding random third-party sources

If you’ve ever copy-pasted a repo line at 2 a.m. to install one tool—this is where the bill comes due. Mixed repos create dependency conflicts that look exactly like “kept back” issues… except harder.

Mistake #3: Pinning/holding packages without a written reason

Package holds can be valid (especially for drivers). But if you can’t explain the hold in one sentence, you’re basically leaving a trap for Future You.

Mistake #4: Ignoring removals that quietly nuke your Kali experience

If simulation wants to remove a desktop environment, a core meta-package, or your network stack, stop and investigate. That’s not “APT being dramatic.” That’s APT asking for a major change.

Don’t do this: risky “fixes” that backfire on Rolling

Don’t force-install with dpkg -i roulette (and then blame APT)

Yes, you can download a random .deb and install it manually. That doesn’t mean you should. Manual installs can bypass the solver’s safety rails and leave you with a fragile half-upgraded state.

Don’t mass-remove desktop/meta packages unless you mean to

If you see removals like kali-desktop-* or a desktop meta-package you rely on, pause. Sometimes it’s legitimate during transitions; often it’s a sign something upstream is temporarily inconsistent.

Don’t “fix” dependency conflicts with copy-pasted purge commands

Purging blindly is how you turn a solvable dependency issue into a weekend project. Use simulation, then choose a targeted action.

Show me the nerdy details

Blind purges often remove packages that are anchors in the dependency graph (desktop meta-packages, kernels, drivers). Once removed, APT may propose a different “best” solution that isn’t aligned to your actual use case.

Who this is for / not for

For: Kali Rolling users who accept repo churn and want consistent upgrades

If you treat Kali as a living toolbox and you update with intention (not impulse), this workflow fits you. You’ll get faster fixes and fewer surprises. If your environment includes remote boxes, pair this with Kali SSH hardening so an “easy upgrade day” doesn’t accidentally become an “easy intrusion day.”

Not for: stability-first systems (consider Kali “last” or a stable base OS)

If this machine is your only work computer and downtime is unacceptable, rolling release behavior will feel hostile. In that case, a stable base OS plus Kali tools in containers/VMs can be calmer.

For: VM lab machines vs for: daily driver laptops (different risk tolerance)

On a VM, snapshots are cheap and courage is easy. On a daily driver with proprietary drivers and weird Wi-Fi firmware, you want more caution—and more simulation.

Edge cases: when full-upgrade still won’t move (and what it’s telling you)

Held packages (apt-mark hold) vs “kept back” (similar words, different causes)

“Kept back” is APT choosing not to upgrade due to constraints. “Held” means you explicitly pinned a package to stay put. If something is held, full-upgrade won’t magically override your decision.

apt-mark showhold

Broken dependencies and partial upgrades (how to spot and unwind)

If installs were interrupted, or the package database is in a weird state, APT may refuse to proceed cleanly. In that case, solve the broken state first—then rerun simulation.

• sudo dpkg --configure -a (finish configuring unpacked packages)
• sudo apt -f install (attempt to fix broken dependencies)

Drivers/NVIDIA/VirtualBox/VMware: the usual conflict zones

Proprietary drivers and VM integration packages are common sources of “kept back” because they depend on specific kernel headers and module builds. If you see NVIDIA-related packages in removals, don’t panic—just slow down and verify what you’ll reinstall after.

Real-world note: I’ve watched VirtualBox guest additions and VMware tools drift out of sync after upgrades. It’s not fatal, but it is annoying—especially when your clipboard stops working at exactly the wrong time. If you’re in VirtualBox pain already, bookmark Kali VirtualBox “no sound after update” fixes as a reminder that “small drift” becomes “weird symptoms” fast.

If you’re choosing VMware flavors for a lab machine, the practical differences in VMware Player vs Workstation vs Fusion also show up in how pleasant recovery feels after a bumpy upgrade.

When waiting 24–48 hours is the correct fix on Rolling

Sometimes the right move is: do nothing for a day. Rolling repos can briefly land in a state where not all dependent packages are available at the same time. If simulation proposes removing half your desktop, that can be a signal to wait, update your package lists later, and re-simulate.

Recovery plan if something went sideways (no panic, just sequence)

If a desktop disappears: reinstall the right meta-package path

If a desktop environment vanishes, don’t treat it like a mystery. Identify what you actually want (XFCE, GNOME, KDE), then reinstall the appropriate Kali desktop meta-package. Keep it deliberate; don’t shotgun-install every desktop because you’re stressed.

If networking breaks: firmware + kernel module checks

Networking issues after upgrades are often a firmware or module mismatch problem. Confirm your kernel version, check that firmware packages are present, and review logs. (If you’re debugging “it connects but it leaks,” keep a dedicated fix note like ProxyChains DNS leak remediation—same genre of problem, same disciplined approach.)

uname -r
dmesg | tail -n 80
journalctl -b -p err --no-pager | tail -n 80

If you can’t boot: snapshot strategy and rollback muscle memory

On VMs, snapshots are your best friend. On bare metal, having a rescue USB and a calm sequence beats improvisation. This is why “simulate first” is not just etiquette—it’s insurance. If you’re dual-booting, the most common “I can’t boot” fix path looks like Kali dual boot GRUB recovery. And if you live on a portable setup, Kali persistent USB with Secure Boot is the difference between “lab on demand” and “lab on fire.”

Next step

Run a simulation now: apt -s full-upgrade, scan for removals, then execute apt full-upgrade if the plan looks sane

Here’s the 15-minute “do it now” sequence:

1. sudo apt update
2. sudo apt -s full-upgrade (read removals)
3. sudo apt full-upgrade
4. sudo apt autoremove --purge
5. Reboot if kernel/core libraries updated

If you want official wording and troubleshooting patterns, Kali’s APT troubleshooting page is genuinely useful (rare compliment, I know). And if your “kept back” list includes Ruby tooling, don’t underestimate version drift—this is the same flavor of headache as msfconsole bundler/Ruby version mismatch: solvable, but only if you stop guessing.

FAQ

Closing the loop: make full-upgrade boring again

Remember the line everyone skims? The one that quietly tells you whether APT needs to install something new or remove a conflict? That’s the whole game. Once you treat “kept back” as a permission question—not a mystery—the fix becomes boring in the best way.

If you want official guidance and common APT error patterns from Kali, use their troubleshooting page. If you want the formal definition of what full-upgrade is allowed to do, Debian’s APT man page says it plainly.

Your best next move—right now, within 15 minutes—is simple: run the simulation, read the removals, and either proceed or wait with confidence. The goal isn’t “never see kept back again.” The goal is: when you see it, you know exactly what to do.

Last reviewed: 2025-12.