167

My first issue was when I tried to apt-get update or apt-get upgrade. On upgrade I get the following error:

You might want to run 'apt-get -f install' to correct these.
The following packages have unmet dependencies:
linux-image-server : Depends: linux-image-3.2.0-27-generic but it is not installed
E: Unmet dependencies. Try using -f.

I tried running apt-get install -f and this was the output(after saying yes on prompt)

(Reading database ... 186183 files and directories currently installed.)
Unpacking linux-image-3.2.0-27-generic (from .../linux-image-3.2.0-27-generic_3.2.0-27.43_amd64.deb) ...
Done.
dpkg: error processing /var/cache/apt/archives/linux-image-3.2.0-27-generic_3.2.0-27.43_amd64.deb (--unpack):
 failed in write on buffer copy for backend dpkg-deb during `./boot/System.map-3.2.0-27-generic': No space left on device
 No apport report written because the error message indicates a disk full error
                                                                          dpkg-deb:    error: subprocess paste was killed by signal (Broken pipe)
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.2.0-27-generic   /boot/vmlinuz-3.2.0-27-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.2.0-27-generic /boot/vmlinuz-3.2.0-27-generic
Errors were encountered while processing:
/var/cache/apt/archives/linux-image-3.2.0-27-generic_3.2.0-27.43_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

I tried running apt-get autoremove and it gives me the same error as apt-get upgrade.

When I run df, I get this for /boot:

/dev/sda1                    233191     230297         0 100% /boot

So, I read elsewhere that I should try to purge old kernels. I checked for what kernels I had with:

$ dpkg -l linux-image-\* | grep ^ii
ii  linux-image-2.6.38-13-server  2.6.38-13.52  Linux kernel image for version 2.6.38 on x86_64
ii  linux-image-3.0.0-13-server   3.0.0-13.22   Linux kernel image for version 3.0.0  on x86_64
ii  linux-image-3.0.0-14-server   3.0.0-14.23   Linux kernel image for version 3.0.0  on x86_64
ii  linux-image-3.0.0-15-server   3.0.0-15.26   Linux kernel image for version 3.0.0  on x86_64
ii  linux-image-3.0.0-16-server   3.0.0-16.29   Linux kernel image for version 3.0.0  on x86_64
ii  linux-image-3.0.0-17-server   3.0.0-17.30   Linux kernel image for version 3.0.0  on x86_64
ii  linux-image-3.2.0-24-generic  3.2.0-24.39   Linux kernel image for version 3.2.0  on 64 bit x86 SMP
ii  linux-image-3.2.0-25-generic  3.2.0-25.40   Linux kernel image for version 3.2.0  on 64 bit x86 SMP
ii  linux-image-3.2.0-26-generic  3.2.0-26.41   Linux kernel image for version 3.2.0  on 64 bit x86 SMP

When I try to remove the oldest with this:

$ sudo apt-get purge linux-image-2.6.38-13-server
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt-get -f install' to correct these:
The following packages have unmet dependencies:
linux-image-server : Depends: linux-image-3.2.0-27-generic but it is not going to be     installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).

How can I free up or extend boot without messing up my installation?

2

18 Answers 18

146

Freeing Up Space on the Root File System

To free up space on the root file system you can try to execute apt-get clean.

If that doesn't work you can go to /var/cache/apt/archives and manually remove a few files from the cache to get some space back, e.g.:

sudo rm linux-headers-*

It won't hurt to remove all of the .deb files here if you need to - that is what apt-get clean does. They will be automatically be re-downloaded by apt if they are needed again.

Freeing Up Space on the /boot File System

The Original Poster has a separate /boot partition, and that is what is full and preventing the apt system from working. It will be necessary for him to free up space there.

If there almost enough space, go to /boot and remove a config file or two:

sudo rm config-3.2.0-19-generic-pae

for example, but using the name of one of the kernel versions you intend to remove anyway. This will free up a little space (about 144K apiece).

If you need more space individually remove old vmlinuz, initrd, abi and System.map files until you have enough space (about 22M for one of my i386 kernel versions).

Whatever you do, don't remove them all. You should at least keep the latest two matching versions of each kind of file, for each kind of kernel you use.

Then proceed with your apt-get install commands. As mentioned above they may have to re-download some of the debs you deleted, but if so that will happen automatically. When you have apt working again, clean up by using apt-get to remove the packages corresponding to the files you removed - so everything matches.


The config file in /boot is the kernel config that was used by the kernel team to build the kernel of the same name. It should be harmless to remove unless you want it for reference or to aid you in building your own kernels.

Finally you are manually removing an old kernel package or two from the /boot partition to make even more room for the new one.

10
  • I tried removing almost all the configs. It still doesn't seem to have enough space. What other files in there would be safe to remove? My root file system isn't anywhere near full, so I'm not worried about it.
    – Strifey
    Aug 2, 2012 at 16:28
  • I updated my answer with the further files to remove by hand. It seems to me that removing the 3.0.0.13 and 3.0.0.14 sets (five files to the set including the abi file) would suffice. Aug 2, 2012 at 19:42
  • 2
    This fixed it. I realized it would probably come down to removing files by hand, but I'm always hesitant to do that with anything installed by apt, so I thought I'd ask here first.
    – Strifey
    Aug 4, 2012 at 19:13
  • 11
    Do not use sudo rm to remove from /boot. Instead, use sudo dpkg --purge to remove some old linux-image package. Thereafter use sudo apt-get -f install to fix the broken dependency.
    – jarno
    Feb 9, 2016 at 20:48
  • 5
    Though sometime system may be so full that even dpkg can not operate. But rm can be used then.
    – jarno
    Nov 5, 2016 at 17:27
71

In my case, the apt commands and dpkg command could not finish, and could not remove. The autoupdate had failed on installing 2.6.32-56-server.

My first step, was to identify space to be used,

cd /boot
du -sk *|sort -n

I had about 30 kernels and supporting files.

I did a uname -a to get the running kernel, I identified that I was on Linux alternate 2.6.32-43-server and did a tar of 6 of the versions that were not running, and were old.

tar -cvf ~username/boot.tar *2.6.32-44-server *2.6.32-45-server *2.6.32-46-server *2.6.32-47-server *2.6.32-48-server *2.6.32-49-server

I then did a rm -rf of what I had backed up:

rm -rf *2.6.32-44-server *2.6.32-45-server *2.6.32-46-server *2.6.32-47-server *2.6.32-48-server *2.6.32-49-server

I am showing these commands as examples, you will have to decide what you will work with for your situation.

Now that I had some space on /boot, I was able to run

apt-get -f install 

To clean up the failed install of 2.6.32-56-server.

I then did a

apt-get remove linux-headers-2.6.32-38 linux-headers-2.6.32-38-server linux-image-2.6.32-38-server
apt-get remove linux-headers-2.6.32-39 linux-headers-2.6.32-39-server linux-image-2.6.32-39-server

This gave me room to put back what I had backed up.

tar -xf ~username/boot.tar
rm  ~username/boot.tar    

To clean up, I then could run:

apt-get autoremove

I rebooted and am now down to using 4% of /boot.

2
  • This was the most helpful for me out of all of the suggestions. Thank you very much! Mar 28, 2015 at 1:53
  • removing files from /boot just horribly breaks apt and dpkg since thier install and removal scripts fail HARD when the files are missing. I don't see how you got this to work.
    – FizxMike
    Jun 11, 2016 at 22:54
22

You can use dpkg instead of apt-get to remove older kernels:

sudo dpkg -r linux-image-3.2.0-29-generic
4
  • Maybe there are plusses for using this, but @mreiter's suggestion worked for me when this one didn't (this one was suggested on ubuntu's IRC support channel.)
    – Aaron Hall
    Mar 28, 2015 at 13:09
  • 3
    @AaronHall This answer simply contains the key part of mreiter’s answer (the last line) and it’s much shorter since it does not cover cleaning of headers (which does not help in the case of separate /boot partition).
    – Melebius
    Apr 6, 2017 at 10:27
  • A couple of reminders: use uname -r to know the kernel that you must NOT remove (the one you're currently using). Also, when you're done removing old kernels, remember to run apt-get -f install to fix possible broken dependencies.
    – Yajo
    Jan 28, 2020 at 9:25
  • This option fails if /boot has no space left
    – Alf Pascu
    Jul 18, 2021 at 20:15
10

I noticed there were still some files of the old versions in the boot directory:

$ ls /boot
vmcoreinfo-2.6.31-17-server

And the package manager would list the old versions:

dpkg -l | grep linux-image

I therefore used this command (autoremove would also remove more recent images I don't want to remove)

sudo apt-get purge linux-image-2.6.31-17-server

I had still some headers left:

dpkg -l | grep linux-headers

So I did this:

sudo apt-get purge linux-headers-2.6.32-34

Finally there was one package left I couldn't remove with apt-get purge:

$ dpkg -l | grep linux-image
rc  linux-image-2.6.28-11-server

Source: Remove a package marked as rc by dpkg

sudo dpkg --purge linux-image-2.6.28-11-server
0
3

I found that the only thing that worked for me was using Aptitude.

sudo aptitude

Then when it opens it will usually say something about unmet dependencies on the bottom. You can hit the letter g to proceed with the suggested removal. It will take you to a page where it lists what is going to happen.

There should be a minus - next to the broken kernels. Press g again and it will remove the broken kernels. Press q to quit. Then you should be able to use sudo apt-get autoremove to get rid of the old kernels and free up space.

UPDATE 2022: Another way is to manually remove some kernel files, especially if aptitude isn't installed:

First check your running kernel to make sure you don't delete it:

uname -r

Then list the modules directory:

ls /usr/lib/modules/

For example, here is a list from one of my servers:

drwxr-xr-x 5 root root 4096 Mar  2 14:16 5.4.0-100-generic
drwxr-xr-x 2 root root  250 Apr 27  2021 5.4.0-26-generic
drwxr-xr-x 2 root root  250 May 13  2021 5.4.0-28-generic
drwxr-xr-x 2 root root  250 Oct 26 14:01 5.4.0-72-generic
drwxr-xr-x 2 root root  250 Oct 26 14:01 5.4.0-73-generic
drwxr-xr-x 2 root root  250 Oct 26 14:01 5.4.0-80-generic
drwxr-xr-x 2 root root  250 Mar 11 16:20 5.4.0-84-generic
drwxr-xr-x 2 root root  250 Mar 11 16:20 5.4.0-89-generic
drwxr-xr-x 2 root root  250 Mar 11 16:20 5.4.0-91-generic
drwxr-xr-x 5 root root 4096 Feb  1 14:15 5.4.0-97-generic

Remove all but the newest 2 from this directory. For example:

sudo rm -rf 5.4.0-26-generic 5.4.0-28-generic 5.4.0-72-generic 5.4.0-73-generic 5.4.0-80-generic 5.4.0-84-generic 5.4.0-89-generic 5.4.0-91-generic

Also check the /boot directory and do the same process there.

Then check to see if some space was freed up:

df -h

Finally run apt to fix the broken packages:

sudo apt -f install
1
  • 1
    this is the ONLY valid answer. all of the other answers didn't worked, as the package manager wanted to install a package before it could remove anything. Sep 24, 2018 at 14:16
2

Check the use of /var/tmp with du -sh /var/tmp/. All files in that folder can be deleted to make space.

You can then run the following to remove the old kernels:

sudo apt-get clean
sudo apt install byobu
sudo purge-old-kernels
sudo apt autoremove
sudo update-grub
2
  • What does /var/tmp have to do with old kernels? And it is not always safe to delete everything in /var/tmp...
    – fosslinux
    Apr 27, 2018 at 7:09
  • IIRC newer versions of byobu do not have purge-old-kernels script. Besides, you could not install byobu, if /boot is full and if there are broken dependencies.
    – jarno
    Jul 5, 2022 at 4:42
2

This is what I used:

sudo apt-get autoremove linux-image-xxxx

Do that for all old kernels and only keep the most recent two.

If you want to automatically remove the old kernels and update GRUB see this: Ubuntu Documentation

2
  • 2
    This should be the accepted answer. If you don't mind cleaning up everything, you don't even need to specify the Linux image.
    – CyberEd
    Dec 22, 2016 at 4:34
  • 1
    I tried this option to remove old kernels (more specifically the one suggested in the Ubuntu documentation, i.e. sudo apt-get autoremove --purge) but it fails because /boot has no space left (which was also the case in the original question)
    – Alf Pascu
    Jul 18, 2021 at 20:13
2

You cannot act upon packages, but you can act upon other files. First, go through your home folder and see whether there is anything you can delete. If not, try to move a good amount of files to another partition (or a flash drive) and then try sudo apt-get install -f to clean up the package dependency issues (most likely you installed a .deb file through dpkg), and then purge any old kernels. Once you safely have at least 10 MB, try purging unneeded software or files.

1
2

Install linux-purge tool like this.

Then run this in terminal:

sudo linux-purge --clear-boot --fix

Then go on removing kernels by e.g.

sudo linux-purge --keep 1 --choose

Extra:

If I recall correctly there is a default setting in Ubuntu 18.04 and later for unattended-upgrades that removes unneeded kernels, but it can not cope with the case that system is already full: The setting is Unattended-Upgrade::Remove-Unused-Kernel-Packages true.

If you want to use linux-purge for unattended kernel removal instead of using unattended-upgrades for that, you should disable removing unused kernels by editing /etc/apt/apt.conf.d/50unattended-upgrades or preferably an overriding separate file (e.g. /etc/apt/apt.conf.d/52unattended-upgrades-local); that means at least setting

Unattended-Upgrade::Remove-Unused-Dependencies false;
Unattended-Upgrade::Remove-Unused-Kernel-Packages false;

Thereafter set up a systemd service executing

/usr/local/bin/linux-purge --auto-only --keep 1 --yes

whenever you want.

3
  • OP cant install anything if its full
    – alchemy
    Feb 11, 2022 at 3:21
  • @alchemy usually it is just separate /boot partition that is full. Besides this does not need package manager for installing.
    – jarno
    Feb 11, 2022 at 11:55
  • The BEST and EASIEST solution! Thanks a lot. Saved
    – Reza Taba
    Jul 3, 2022 at 18:47
1

Use Synaptic Package Manager. Just pick the package you want removed and it will prompt you to also remove packages that depend on it. In my experience, kernel packages always come in groups of two (or more, depending on how you count) that are interdependant. You can usually find old ones quickly by using the "local/obsolete" filter.

1
  • 2
    E.g. on a (text-only) server, there is no Synaptic. So not really a viable solution for servers.
    – nerdoc
    Aug 31, 2017 at 20:41
1

Run this:

sudo apt-get autoremove
sudo apt-get --purge remove && sudo apt-get autoclean
sudo apt-get -f install
sudo dpkg-reconfigure -a

Source: I get this error after upgade. please help

5
  • what does sudo dpkg-reconfigure -a this do? On Ubuntu 16 its says unknown option -a Nov 28, 2017 at 7:59
  • 1
    For this question, apt will fail to remove kernel packages because the removal process itself generates files in /boot, which is already full. That's why apt-get autoremove fails. The question you're looking for is askubuntu.com/q/142926/158442, which already has autoremove, listed.
    – muru
    Jan 23, 2018 at 5:52
  • @muru I just posted it because it did the trick, for me :D Jan 23, 2018 at 14:06
  • I'm sure it did, what I'm saying is that your problem would have been the other question, not this one.
    – muru
    Jan 23, 2018 at 14:08
  • @muru oh ok got it :D Jan 23, 2018 at 14:10
1

I've been fighting with this issue from time to time, and still haven't seen any solution that actually does the full job. In some cases, removing old kernels ends up in dependencies that stops me from removing anything and I had to remove kernels manually from /boot. However, I still wanted apt to do the full job as I imagine the manually deleted kernels are logged somewhere and may cause future problems, when something reports files missing because of me sitting doing rm -rf on files.

So I wrote this script, based on many googled suggestions here that doesn't require any further installation of something. The script has been modified a few times to support some my own "unexpected" situations. For example, running this on a raspberry pi, update-grub probably don't exists. And in some cases when running the last updaters, the servers was stuck with IPv6 where some sites was unreachable.

The script figures out whether it has to forcefully remove kernels that is completly stuck due to dependency builds, ot if it can do it the "right" way.

#!/bin/bash

ipv4="-o Acquire::ForceIPv4=true"

if [ "$1" = "4" ] ; then
    withip=$ipv4
    echo "Going IPv4 ($withip)"
fi

echo "Autoremove+Purge."
apt-get $withip -y -f autoremove --purge >/dev/null 2>&1

if [ "$?" != "0" ] ; then
    echo "Auto Removal Failed!"
fi

echo "Old dependency fix."
apt-get $withip -f -y install >/dev/null 2>&1

if [ "$?" != "0" ] ; then
    echo "That failed. So we'll try to make up to it during this process."
fi

echo "Now, going old kernel cleanup!"
kern=$(dpkg --list 'linux-image*'|awk '{ if ($1=="ii") print $2}'|grep -v `uname -r`)
hadErrors=0

for k in $kern
do
    echo apt-get -y purge $k
    apt-get $withip -y purge $k >/dev/null 2>&1

    if [ "$?" != "0" ] ; then
        echo "Failed apt-purge... Using plan B (--force-all -P)..."
        dpkg --force-all -P $k >/dev/null 2>&1
        echo "Rerunning stuff (apt-get -f -y install) for dependencies..."
        apt-get $withip -f -y install >/dev/null 2>&1
        if [ "$?" != "0" ] ; then
            echo "Still failing..."
            hadErrors=1
        fi
    fi
done

if [ "$hadErrors" = "1" ] ; then
    echo "I had errors. I should rerun this process, to see if there are more kernels that were left out after cleanup..."
    /usr/local/tornevall/cleankernel
fi

apt-get $withip autoremove
apt-get $withip update
apt-get $withip upgrade
apt-get $withip dist-upgrade

grb=$(which update-grub)
if [ "" != "$grb" ] ; then
    update-grub
else
    echo "Can't upgrade grub since update-grub is missing..."
fi
3
  • Did you try linux-purge? It does not have that Force IPv4 thing currently, though.
    – jarno
    Aug 14, 2019 at 8:27
  • Your script would purge linux-image-generic in my system, which is bad.
    – jarno
    Aug 14, 2019 at 8:35
  • They are for some reason being put back when the old kernels has been cleaned up. At least this has been the case for me ever since I built this script. However, this script is something I use when there are no other options to proceed forward. Normally, the upgrades are taking care of this by themselves, but when it comes to this moment, when nothing else works, this may be a good option as there usually comes more kernels that will be set up after the cleanup. If this good or bad is probably discussable. Sep 27, 2019 at 11:19
1

The answer by mreiter is good, but a bit old. Here's my take on freeing up space on /boot and removing old kernels in general:

First check which kernel version you are currently using:

uname -r

In my case I got:

5.11.0-41-generic

List your installed kernel versions:

apt list --installed linux-image*

In my case this gave:

linux-image-5.11.0-40-generic  <-- Can be removed
linux-image-5.11.0-41-generic  <-- In use. Don't remove
linux-image-generic-hwe-20.04  <-- Meta package. Don't remove

Don't purge the kernel version currently in use! Don't purge packages starting with "linux-image-generic". These are meta packages to provide updated kernels. You can now purge (remove including extra / config files) all kernel versions including their modules and headers you are not using:

sudo apt purge linux-image-5.11.0-40-generic linux-modules-5.11.0-40-generic linux-headers-5.11.0-40-generic

apt will tell you what packages it will actually remove. Make sure none of them include your current kernel version. Grub should be updated automatically.

Now you might still have some leftover kernel configs in /boot. You can check this using:

dpkg -l | grep linux-image | grep rc | awk '{ print $2 }' | sort -V

If this lists any packages, purge all of them using:

dpkg -l | grep linux-image | grep rc | awk '{ print $2 }' | sort -V | xargs sudo dpkg --purge

To clean everything else up, run:

sudo apt autoremove && sudo apt autoclean && sudo apt clean

which should auto-remove unused packages and clean up downloaded packages

1
  • This is an excellent answer. Thank you. Oct 5, 2022 at 23:04
0

Simply running sudo apt-get -f autoremove resolved my problem.

2
  • 2
    Did you have 100% disk space /boot usage?
    – fosslinux
    Apr 27, 2018 at 6:58
  • Looking at my monitoring history, it didn't seem to. PS: I am on Vagrant xenial, and my boot file system /dev/sda1 is mounted on /
    – forzagreen
    Apr 29, 2018 at 11:26
0

I've seen a couple articles on /boot being full which is not solved by dpkg purging old linux kernels, because apt-get -f install or apt-get -f autoremove reinstalls the kernels.

In my case, at least, the signed and extra packages also needed to be removed - the kernels were dependencies for these packages so apt reinstalled them. Generally, related kernel packages should be purged before calling 'install'. If you tried to apt-get upgrade right after purging, the error message should have said which packages had an unmet dependency of the kernel you'd just purged.

In my case, the following tactic worked:

#as sudo, repeat 1-3 for any old kernels; can be scripted
dpkg --force-all -P linux-image-4.4.0-112-generic 
dpkg --purge linux-image-extra-4.4.0-112-generic
dpkg --purge linux-signed-image-4.4.0-112-generic
apt-get -f install #dependency resolution didn't have work to do for kernel packages
apt-get autoremove --purge -f 
apt-get autoclean
apt-get upgrade
0

Simple steps to resolve an issue, when /boot is 100% full:

This is a really good article: https://gist.github.com/ipbastola/2760cfc28be62a5ee10036851c654600

TL/DR:

Determine which linux images you have installed:

dpkg -l linux-image-* | awk '/ii/{print $2}'

Pick one, that is not your current kernel and delete corresponding files from boot:

sudo rm /boot/*-OLD_KERNEL_IMAGE_VERSION-*

Example:

sudo rm /boot/*-5.4.0-31-*

Fix "partial install":

sudo apt -f install

Let's do some cleanup:

sudo apt autoremove ; sudo apt clean

Update Grub:

sudo update-grub
1
  • Could you please explain what's the difference with @A.G.Russell answer? Beyond the fact that he is doing a backup and you update the grub, Is it any reason to do it this way?
    – Alf Pascu
    Jul 18, 2021 at 20:33
0

Would recommend making a snapshot before doing this

I did:

uname -a

To get the used kernel version

ls -l /boot

To see all the versions

rm *4.4.0-(old unused versions)*

Then ran

sudo apt -f install

But then got a message: W: mdadm: /etc/mdadm/mdadm.conf defines no arrays. and immediately noticed the /boot filling up again until 100% resulting in the apt erroring out.

But then found this: https://serverfault.com/a/623704

Noticed a similar discrepancy in my configs and ran

/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf
update-initramfs 

Rebooted and then re-ran sudo apt -f install successfully

0

I didnt find this thread when searching, so I started one: How to rescue after apt install or upgrade fills disk space and breaks?, but its a duplicate.

Basically: use apt clean to get some disk space. Then Apt will work again. Then use apt purge <package>. You can find the last installed broken packages using cat /var/log/apt/history.log.

It would be great if Apt would say to "use apt clean if the disk is full", which it could check. It could also check for enough free space before allowing non-forced install.

This post suggests using apt clean and apt install -f to repair the database. I'm not sure apt clean work with apt broken and apt purge showing apt --fix-broken install. apt install -f seems to retry with force the pending install. Disk space issue after apt-get update

Check out my other post for other tips on clearing disk space and also how to prevent it from filling up.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .