Sorry for asking about what is probably really simple, but I've been Googling about for a week now and I've tried a lot of stuff without success.

To start off, I get a pop-up every time I boot saying my /boot partition is full, and the Synaptic Manager says linux-image-generic is broken, but it fails to reinstall either of them (linux-image-extra-3.13.0-54-generic and linux-image-generic).

My terminal tells me to try using install -f to fix things so I've tried that, and this is what it returned. Sadly, I'm still learning and I haven't been able to crack the code, I would like some help

aksel@aksels-PC:~$ sudo apt-get install -f
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Correcting dependencies... Done
The following extra packages will be installed:
Suggested packages:
 fdutils linux-doc-3.13.0 linux-source-3.13.0 linux-tools
The following NEW packages will be installed:
0 upgraded, 1 newly installed, 0 to remove and 344 not upgraded.
5 not fully installed or removed.
Need to get 0 B/14,7 MB of archives.
After this operation, 32,8 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
(Reading database ... 431129 files and directories currently installed.)
Preparing to unpack .../linux-image-3.13.0-54-generic_3.13.0-54.91_i386.deb ...
Unpacking linux-image-3.13.0-54-generic (3.13.0-54.91) ...
dpkg: error processing archive /var/cache/apt/archives/linux-image-3.13.0-54-generic_3.13.0-54.91_i386.deb (--unpack):
 cannot copy extracted data for './boot/vmlinuz-3.13.0-54-generic' to '/boot/vmlinuz-3.13.0-54-generic.dpkg-new': failed to write (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.13.0-54-generic /boot/vmlinuz-3.13.0-54-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.13.0-54-generic /boot/vmlinuz-3.13.0-54-generic
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)

4 Answers 4


By using linux-purge

I have created a helper script for this purpose. It is called linux-purge and its project page is here in Launchpad.net. In the announcements section there are installation instructions here.

In this specific case you would run

sudo linux-purge --fix

Manual method

As an alternative, there are instructions on how to do the task manually at Communiy Wiki Help which I have contributed to (as jarnos).

Anyway, here are my manual instructions as an archive:

First remove any leftover temporary files from previous kernel updates.

sudo rm -rv ${TMPDIR:-/var/tmp}/mkinitramfs-*

(There may be some due to bug in Ubuntu 16.04 and older.)

List the successfully installed kernels excluding booted kernel by command:

dpkg-query -W -f='${Status} ${Package}\n' | awk '/^[^ ]+ ok installed linux-image-[0-9]+/{print $4}' | grep -Fv $(uname -r)

Delete the initrd.img file of an unneeded kernel (due to bug); here the chosen kernel release is 4.2.0-23-generic:

sudo update-initramfs -d -k 4.2.0-23-generic

Purge the kernel by

sudo dpkg --purge linux-image-extra-4.2.0-23-generic linux-image-4.2.0-23-generic

to free some space in /boot. If the command fails, some installed package depends on the kernel. The output of dpkg tells the name of the package. Purge it first.

You may also purge respective header package

sudo dpkg --purge linux-headers-4.2.0-23-generic

and even the common header package

sudo dpkg --purge linux-headers-4.2.0-23

if no other package depends on it; otherwise the command will fail, but it is safe to run.

Then run

sudo apt-get install -f

to fix the broken dependency. If that fails due to insufficient disk space, you have to remove another kernel the way told above.

Note that there still may be too many kernels installed in your system, but now you should be able to purge the extra ones by e.g. sudo apt-get purge followed by kernel package name(s).

  • 1
    +1 for purge-old-kernels which allows much more control over what is kept. E.g. to keep N kernels sudo purge-old-kernels --keep N.
    – mbdevpl
    Commented Jun 15, 2016 at 6:11
  • @mbdevpl now purge-old-kernels is deprecated. For more control, I recommend using linux-purge. Please see the updated answer.
    – jarno
    Commented Jan 28, 2018 at 13:58

The quickest and easiest way to remove old kernels is:

sudo apt-get autoremove

That normally cuts the number of installed kernels down to two or three. Do this after every software update that installs a new kernel to keep the problem from recurring.

  • 1
    Well this is true if he has a few kernels installed but under some situations "autoremove" wont remove an old kernel.
    – JohnRB
    Commented Jun 13, 2015 at 0:06
  • Sometimes, yes; but most of the time it works. It's one command and so is worth trying first.
    – Rod Smith
    Commented Jun 13, 2015 at 0:42
  • 1
    I have tried this earlier, sadly it did nothing
    – Dooblieve
    Commented Jun 13, 2015 at 8:43
  • In that case, you should follow the more complex advice given by others. Also, what size is your /boot partition? (You can learn this by typing df -h /boot.) I generally recommend a /boot partition of 500MiB or thereabouts. If it's smaller than about half that, it will fill up too quickly. It's possible to resize partitions, but doing so carries some risk, especially if you have to move the start point.
    – Rod Smith
    Commented Jun 13, 2015 at 14:38
  • Downvoted, because the solution does not work in this specific case. Also autoremoving works only for "automatically" installed kernels (and other packages); it does not work for kernels installed (manually) using Software Updates in Thrusty, see Bug #1492709.
    – jarno
    Commented Feb 10, 2016 at 8:25

Well it is not surprising the apt-get functions are failing if your /boot partition is full. You just have to free up space in your /boot, you can do it graphically or via terminal/ssh whatever you are more comfortable with. You can purge (not remove!) unneeded packages taking up space (kernels since its your /boot part), or you can expand your /boot partition making it larger then you can run the -f command again. If that all is a different language to you I will need more info to give you exact commands you need to run in order to do so.

  1. List your installed kernels with: dpkg -l | grep linux-image-
  2. How are system partitions layed out (what does cat /etc/fstab output)?
  3. List your disc space with: df command.

Here is a link that should help Removing Old Kernels

  • checking out the link. In the meantime here's the output of your second point: i.imgur.com/wa0HL6f.png
    – Dooblieve
    Commented Jun 13, 2015 at 8:24
  • u fix this sorry I have not had time and did not see your response? I hope so because you have a whole list of answers here. lol If not let me know and I will hold your hand and walk you threw it.
    – JohnRB
    Commented Jul 3, 2015 at 22:03

You have run out of space on your boot partition. That is why apt-get fails, it even tells you so

No apport report written because the error message indicates a disk full error

Remove old kernels before (re)installing, leave most recent and one previous.

#dpkg -l | grep linux-image-

will list all installed kernels

sudo apt-get autoremove linux-image-##fill-in-with-result-from-previous-command##

will remove them

$apt-get install --reinstall linux-image-generic

will do the rest

Official Ubuntu Page about removing old kernels

  • 1
    apt-get refuses to remove anything, because the last kernel it tried to install didn't fit on /boot, leaving unmet dependencies. Those dependencies can't be installed due to lack of space, and really old kernels can't be installed, because of unmet dependencies in the global package list. :(
    – Ben Voigt
    Commented Nov 18, 2015 at 15:51
  • 1
    try this: #dpkg -l | grep linux-image- #dpkg --force-all -P linux-image-##fill-in-with-result-from-previous-command##
    – czapa.ols
    Commented Nov 26, 2015 at 3:27
  • Yes, dpkg can still remove things even when apt-get is stuck on dependency resolution.
    – Ben Voigt
    Commented Nov 26, 2015 at 3:32

You must log in to answer this question.

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