You run apt update && apt full-upgrade on your Proxmox VE host like you have a dozen times before, and this time it stops halfway through with something like dpkg: error processing package proxmox-kernel-6.8.12-9-pve (--configure): unable to install new version of '/boot/vmlinuz-6.8.12-9-pve': No space left on device. Nothing was wrong with your disk an hour ago. What happened is that every kernel update you've ever applied is still sitting on your host, and /boot finally ran out of room to fit one more.
This is one of those problems that sneaks up on people. You install Proxmox VE once, forget it exists for six months, and by the time you check back there are eight or nine kernel versions stacked up eating space that was never meant to hold more than three or four. The fix is quick once you know what's safe to delete. Getting there without breaking your bootloader is the part that trips people up.
What You Will Learn
By the end of this guide you'll know how to check exactly how full /boot is and which kernels are eating the space, how to tell the kernel you're currently running from the ones you can safely remove, how to purge the old ones with apt without touching the packages that keep your system bootable, and how to make sure proxmox-boot-tool is happy with the result afterward. We'll also cover the errors people run into along the way, since "no space left on device" is rarely the only message you'll see during this process.
What Is This Feature?
Every time Proxmox VE ships a kernel update, it lands as a brand new package rather than replacing the one you already have. A package named proxmox-kernel-6.8.12-9-pve and one named proxmox-kernel-6.8.12-4-pve can both be installed on the same host at the same time, each with its own vmlinuz and initrd.img file living in /boot. That's by design — it's what lets you boot into an older kernel from the GRUB or systemd-boot menu if a new one turns out to break your NIC driver or your GPU passthrough.
The catch is that Debian, and Proxmox VE with it, does not quietly remove those old kernel packages on its own. Nothing goes looking through /boot deciding what's safe to throw away during a routine apt upgrade. Each kernel stays installed, and each one keeps its files on disk, until you explicitly tell apt to get rid of it.
On a Proxmox VE install, /boot lives on your root filesystem rather than on a separate small partition in most default setups, but that doesn't make it immune to filling up — a modest root disk, or one that's mostly given over to VM storage, can still run out of headroom after enough kernel releases pile up. If you're on a system where proxmox-boot-tool manages EFI System Partitions (common on ZFS-root installs), those ESPs are fixed in size — 512 MB by default on a fresh install — and every kernel version gets copied onto each one. A handful of kernels, each with a compressed image and initrd typically in the 60–120 MB range depending on your hardware and any extra drivers baked into the initrd, adds up faster than people expect.
Why Would You Use It?
You're not choosing to clean up old kernels for fun — you're doing it because apt just failed, or because you noticed df -h creeping toward 100% and want to get ahead of it before an update breaks mid-install. Either way, the underlying reason is the same: kernel packages are one of the few things on a Proxmox host that grow completely on their own, with zero action from you, every time you patch the system. If you update monthly and never clean up, it's normal to end up with six, eight, sometimes a dozen old kernels installed a year or two into running a host.
There's a real cost to leaving it alone beyond the disk space. A host that can't write a new kernel to /boot during an update leaves that update in a half-configured state — the package manager thinks the new kernel is only partially installed, and every subsequent apt command complains about it until you either free up space or remove the broken entry. It's a nuisance you want to fix once, cleanly, rather than fight every time you patch.
Prerequisites
- Root or sudo access to your Proxmox VE host, either through the web shell (Datacenter → your node → Shell) or SSH.
- A host you can safely reboot. You'll want to confirm the system still boots cleanly after cleanup, and that means a reboot at some point — don't do this cleanup remotely on a box with no other way in if you're not confident about the network config surviving a reboot.
- Roughly ten minutes, most of which is just watching
aptandproxmox-boot-tooldo their thing.
You don't need to be on any particular Proxmox VE version for this — the same mechanism applies whether you're running an 8.x host or a current 9.x install. The kernel package name changed from pve-kernel-* to proxmox-kernel-* starting with Proxmox VE 8.1, so if you're on an older host you may see the old naming in your output. The commands below work either way; just swap the package name pattern.
Step-by-Step Tutorial
Step 1: Confirm you actually have a space problem
Start by checking how full things really are:
df -h /boot
df -h /If /boot is its own mount point, you'll see it listed separately; on most default installs it isn't, and you'll just be looking at your root filesystem's usage. Anything above 90% on whichever one holds /boot is worth cleaning up now, before your next kernel update turns "worth cleaning up" into "broken update."
Step 2: Find out which kernel you're actually running
This is the one you cannot remove under any circumstances:
uname -rWrite that version string down, or keep the terminal open. Everything else in this guide is about clearing out the kernels that aren't this one.
Step 3: List every kernel package installed on the host
dpkg -l | grep -E 'proxmox-kernel|pve-kernel'You'll get a wall of output. Ignore the meta-packages for a moment — things like proxmox-kernel-6.8 with no build number after it — and focus on the fully versioned entries, the ones that look like proxmox-kernel-6.8.12-9-pve. Those are the actual installed kernel images, each with its own files in /boot. It's normal to see four, six, sometimes ten of these on a host that's been running a while.
Step 4: Decide what to keep
A sane rule for a homelab or small production host: keep the kernel you're currently running, keep the one immediately before it in case you need to fall back, and remove everything older than that. If your GPU passthrough or a specific NIC driver only works on one particular older kernel, keep that one too and just be aware it'll need re-removing manually later — apt autoremove won't know it's special to you.
Step 5: Remove the old kernel packages
For each version you've decided to drop, purge it by exact package name:
apt remove --purge proxmox-kernel-6.8.12-4-pve
apt remove --purge proxmox-kernel-6.8.12-1-pveRemoving them one at a time like this, rather than all at once with a wildcard, gives you a chance to read each confirmation prompt and make sure you're not about to remove the kernel you're currently booted into — apt will normally refuse that outright, but it's still worth reading what it's about to do.
Step 6: Let apt clean up what's left over
Once the explicit removals are done, run:
apt autoremove --purgeThis clears out any header packages, leftover kernel-related dependencies, and orphaned files that came along with the kernels you just removed but weren't removed automatically. Read the list of packages it's about to remove before confirming — autoremove isn't scoped to kernels specifically, so on a host where you've installed and later removed other software, it can occasionally list packages you didn't expect. If anything on that list looks unrelated to kernels, stop and check it before continuing.
Step 7: Sync the bootloader
If your host uses proxmox-boot-tool to manage EFI System Partitions — which is the default on ZFS-root installs, and common on others too — run:
proxmox-boot-tool refreshThis pushes the current kernel list out to every ESP it knows about, so the boot menu matches what's actually installed. On a GRUB-only setup without proxmox-boot-tool managing ESPs, this step usually runs itself as part of the package removal, but it costs nothing to run it manually and confirm.
Step 8: Check the result and reboot
proxmox-boot-tool status
df -h /bootproxmox-boot-tool status should show each ESP as synced with no errors. Once that's clean, reboot the host and confirm it comes back up on the kernel you expected:
uname -rIf that matches what you noted in Step 2, you're done.
Commands Explained
| Command | What it does |
|---|---|
uname -r | Prints the kernel version the running system booted from right now. |
dpkg -l | grep proxmox-kernel | Lists every installed kernel package, including old ones you're no longer using. |
apt remove --purge <package> | Uninstalls a specific package and deletes its configuration files, rather than just marking it removed. |
apt autoremove --purge | Removes packages that were pulled in as dependencies and are no longer needed by anything else installed. |
proxmox-boot-tool refresh | Copies the current set of kernels and initrds out to every EFI System Partition Proxmox VE is tracking, keeping them all bootable. |
proxmox-boot-tool status | Reports which ESPs are configured and whether they're currently in sync. |
Common Errors
"No space left on device" during dpkg configure. This is the error that sends most people here in the first place. It means apt got partway through installing a new kernel and ran out of room to finish writing its files. Free up space using the steps above, then run apt --fix-broken install to let the interrupted update finish.
"E: Sub-process /usr/bin/dpkg returned an error code (1)". A generic wrapper error that usually points back to the same disk-space failure underneath it. Scroll up in the output to find the actual line that failed — it's almost always the same "no space left on device" message a few lines earlier.
"dpkg: warning: while removing proxmox-kernel-X, directory '/boot' not empty so not removed". Harmless. This just means other kernel packages still have files in /boot, which is expected — the directory itself only gets cleaned up if you remove every kernel package, which you never should.
apt refuses to remove your running kernel. That's apt doing its job correctly. If you genuinely need to remove the kernel you're currently booted into — rare, but it happens after a migration — reboot into a different installed kernel first, then remove the one you were previously running.
Troubleshooting
If you're still tight on space after removing the obviously old kernels, check whether kernel header packages are also piling up:
dpkg -l | grep pve-headersThese aren't strictly necessary on a Proxmox VE host unless you're building custom kernel modules, and apt autoremove --purge usually catches them once their matching kernel is gone — but it's worth a manual check if space is still tight.
If proxmox-boot-tool status shows an ESP as out of sync after you've already run refresh, check whether that partition itself is full — remember it's a separate, fixed-size filesystem from your root disk, typically 512 MB, and it can run out of room independently of everything else on the host. proxmox-boot-tool status -v gives more detail on exactly which ESP is having trouble.
If a reboot after cleanup leaves you stuck at a GRUB rescue prompt or an empty boot menu, don't panic and don't reinstall. Boot from the Proxmox VE installer in rescue mode, mount your root filesystem, and re-run proxmox-boot-tool refresh from within the rescue environment — this rebuilds the boot configuration from what's actually installed rather than whatever got left in a half-updated state.
Best Practices
Check kernel disk usage every time you do a round of updates, not just when something breaks. It takes ten seconds to run df -h /boot before and after an apt upgrade, and it turns this into a non-event instead of an outage.
Keep two kernels installed, not one. Running with only the very latest kernel and nothing to fall back on means a single bad update can leave you with no working boot option except a live rescue environment. Two is enough of a safety net for almost everyone without wasting meaningful space.
Don't script blind mass-removal of every kernel except the newest. If you automate cleanup, automate it to always preserve the currently running kernel plus at least one prior version, and log what got removed. A cron job that deletes "everything but the latest" is exactly how people end up unable to boot after a bad kernel release, because the fallback they needed was already gone.
Frequently Asked Questions
Is it safe to just delete files out of /boot by hand instead of using apt?
No. Deleting vmlinuz or initrd.img files directly leaves dpkg thinking those packages are still installed, which breaks future updates in confusing ways. Always remove kernels through apt remove --purge so the package database stays accurate.
Why does Proxmox VE keep old kernels installed instead of removing them automatically?
So you have a working fallback if a new kernel breaks something on your specific hardware. It's a deliberate tradeoff between convenience and safety, and it leans toward safety by default.
Will this affect my running VMs or containers?
No. Removing old host kernel packages and rebooting the Proxmox VE host itself doesn't touch the disks, configuration, or data belonging to your VMs and containers. They'll just restart along with the host if you have them set to autostart, same as any other host reboot.
How many kernels should I realistically keep around?
Two is a reasonable default for most homelab and small business setups — the one you're running, and one to fall back on. If you're chasing a specific hardware compatibility issue, keep whichever known-good version fixes it as a third, and remove it once the issue is resolved upstream.
Do I need to do anything special on a ZFS root install versus ext4?
The commands are identical either way. The only practical difference is that ZFS-root hosts almost always rely on proxmox-boot-tool to manage EFI System Partitions, so running proxmox-boot-tool refresh after cleanup matters more there than on a simple GRUB/ext4 setup.
Conclusion
A full /boot is one of the more avoidable outages you'll run into on a Proxmox VE host, and also one of the quickest to fix once you know the pattern: figure out what you're running, remove what you're not, let autoremove sweep up the leftovers, and sync the bootloader before you reboot. Do a quick df -h check the next few times you patch the host, and you likely won't see this error again.