My /boot partition hit 100% and now I can't upgrade. Can't remove old kernels to make room












146















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?










share|improve this question

























  • I think @mreiter's answer may be the best: it uses the package manager, and it worked when other package manager commands failed, at least for me: askubuntu.com/a/205776/247661

    – Aaron Hall
    Mar 28 '15 at 13:16











  • I have made a script that does the job. I will publish it after my bounty goal is reached: bountysource.com/issues/…

    – jarno
    Nov 5 '16 at 17:38






  • 3





    help.ubuntu.com/community/RemoveOldKernels

    – dskrvk
    Jun 8 '17 at 15:00






  • 1





    @dskrvk Yes! Why is Remove-Unused-Dependencies not the default?

    – Steven R. Loomis
    Dec 5 '17 at 19:22
















146















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?










share|improve this question

























  • I think @mreiter's answer may be the best: it uses the package manager, and it worked when other package manager commands failed, at least for me: askubuntu.com/a/205776/247661

    – Aaron Hall
    Mar 28 '15 at 13:16











  • I have made a script that does the job. I will publish it after my bounty goal is reached: bountysource.com/issues/…

    – jarno
    Nov 5 '16 at 17:38






  • 3





    help.ubuntu.com/community/RemoveOldKernels

    – dskrvk
    Jun 8 '17 at 15:00






  • 1





    @dskrvk Yes! Why is Remove-Unused-Dependencies not the default?

    – Steven R. Loomis
    Dec 5 '17 at 19:22














146












146








146


60






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?










share|improve this question
















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?







upgrade apt partitioning






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 27 '18 at 7:23









ubashu

2,37321837




2,37321837










asked Aug 2 '12 at 15:17









Strifey16Strifey16

8322711




8322711













  • I think @mreiter's answer may be the best: it uses the package manager, and it worked when other package manager commands failed, at least for me: askubuntu.com/a/205776/247661

    – Aaron Hall
    Mar 28 '15 at 13:16











  • I have made a script that does the job. I will publish it after my bounty goal is reached: bountysource.com/issues/…

    – jarno
    Nov 5 '16 at 17:38






  • 3





    help.ubuntu.com/community/RemoveOldKernels

    – dskrvk
    Jun 8 '17 at 15:00






  • 1





    @dskrvk Yes! Why is Remove-Unused-Dependencies not the default?

    – Steven R. Loomis
    Dec 5 '17 at 19:22



















  • I think @mreiter's answer may be the best: it uses the package manager, and it worked when other package manager commands failed, at least for me: askubuntu.com/a/205776/247661

    – Aaron Hall
    Mar 28 '15 at 13:16











  • I have made a script that does the job. I will publish it after my bounty goal is reached: bountysource.com/issues/…

    – jarno
    Nov 5 '16 at 17:38






  • 3





    help.ubuntu.com/community/RemoveOldKernels

    – dskrvk
    Jun 8 '17 at 15:00






  • 1





    @dskrvk Yes! Why is Remove-Unused-Dependencies not the default?

    – Steven R. Loomis
    Dec 5 '17 at 19:22

















I think @mreiter's answer may be the best: it uses the package manager, and it worked when other package manager commands failed, at least for me: askubuntu.com/a/205776/247661

– Aaron Hall
Mar 28 '15 at 13:16





I think @mreiter's answer may be the best: it uses the package manager, and it worked when other package manager commands failed, at least for me: askubuntu.com/a/205776/247661

– Aaron Hall
Mar 28 '15 at 13:16













I have made a script that does the job. I will publish it after my bounty goal is reached: bountysource.com/issues/…

– jarno
Nov 5 '16 at 17:38





I have made a script that does the job. I will publish it after my bounty goal is reached: bountysource.com/issues/…

– jarno
Nov 5 '16 at 17:38




3




3





help.ubuntu.com/community/RemoveOldKernels

– dskrvk
Jun 8 '17 at 15:00





help.ubuntu.com/community/RemoveOldKernels

– dskrvk
Jun 8 '17 at 15:00




1




1





@dskrvk Yes! Why is Remove-Unused-Dependencies not the default?

– Steven R. Loomis
Dec 5 '17 at 19:22





@dskrvk Yes! Why is Remove-Unused-Dependencies not the default?

– Steven R. Loomis
Dec 5 '17 at 19:22










11 Answers
11






active

oldest

votes


















124














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.






share|improve this answer


























  • 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.

    – Strifey16
    Aug 2 '12 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.

    – John S Gruber
    Aug 2 '12 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.

    – Strifey16
    Aug 4 '12 at 19:13






  • 9





    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 '16 at 20:48






  • 3





    Though sometime system may be so full that even dpkg can not operate. But rm can be used then.

    – jarno
    Nov 5 '16 at 17:27



















62














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.






share|improve this answer


























  • This was the most helpful for me out of all of the suggestions. Thank you very much!

    – Joshua F. Rountree
    Mar 28 '15 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 '16 at 22:54



















19














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



sudo dpkg -r linux-image-3.2.0-29-generic





share|improve this answer
























  • 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 '15 at 13:09








  • 2





    @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 '17 at 10:27



















9














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





share|improve this answer

































    3














    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






    share|improve this answer





















    • 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 '16 at 4:34



















    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





    share|improve this answer


























    • What does /var/tmp have to do with old kernels? And it is not always safe to delete everything in /var/tmp...

      – ubashu
      Apr 27 '18 at 7:09





















    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.






    share|improve this answer





















    • 5





      The home folder is not in /boot

      – Thorbjørn Ravn Andersen
      May 17 '13 at 8:05



















    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.






    share|improve this answer



















    • 1





      E.g. on a (text-only) server, there is no Synaptic. So not really a viable solution for servers.

      – nerdoc
      Aug 31 '17 at 20:41



















    1














    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.






    share|improve this answer


























    • 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.

      – machineaddict
      Sep 24 '18 at 14:16



















    0














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






    share|improve this answer



















    • 2





      Did you have 100% disk space /boot usage?

      – ubashu
      Apr 27 '18 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 '18 at 11:26



















    0














    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






    share|improve this answer


























    • what does sudo dpkg-reconfigure -a this do? On Ubuntu 16 its says unknown option -a

      – Shivam Kotwalia
      Nov 28 '17 at 7:59











    • 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 '18 at 5:52













    • @muru I just posted it because it did the trick, for me :D

      – Ardi Nusawan
      Jan 23 '18 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 '18 at 14:08











    • @muru oh ok got it :D

      – Ardi Nusawan
      Jan 23 '18 at 14:10











    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "89"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f171209%2fmy-boot-partition-hit-100-and-now-i-cant-upgrade-cant-remove-old-kernels-to%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    11 Answers
    11






    active

    oldest

    votes








    11 Answers
    11






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    124














    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.






    share|improve this answer


























    • 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.

      – Strifey16
      Aug 2 '12 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.

      – John S Gruber
      Aug 2 '12 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.

      – Strifey16
      Aug 4 '12 at 19:13






    • 9





      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 '16 at 20:48






    • 3





      Though sometime system may be so full that even dpkg can not operate. But rm can be used then.

      – jarno
      Nov 5 '16 at 17:27
















    124














    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.






    share|improve this answer


























    • 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.

      – Strifey16
      Aug 2 '12 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.

      – John S Gruber
      Aug 2 '12 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.

      – Strifey16
      Aug 4 '12 at 19:13






    • 9





      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 '16 at 20:48






    • 3





      Though sometime system may be so full that even dpkg can not operate. But rm can be used then.

      – jarno
      Nov 5 '16 at 17:27














    124












    124








    124







    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.






    share|improve this answer















    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.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Apr 27 '18 at 7:22









    ubashu

    2,37321837




    2,37321837










    answered Aug 2 '12 at 15:54









    John S GruberJohn S Gruber

    11.5k32958




    11.5k32958













    • 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.

      – Strifey16
      Aug 2 '12 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.

      – John S Gruber
      Aug 2 '12 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.

      – Strifey16
      Aug 4 '12 at 19:13






    • 9





      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 '16 at 20:48






    • 3





      Though sometime system may be so full that even dpkg can not operate. But rm can be used then.

      – jarno
      Nov 5 '16 at 17:27



















    • 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.

      – Strifey16
      Aug 2 '12 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.

      – John S Gruber
      Aug 2 '12 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.

      – Strifey16
      Aug 4 '12 at 19:13






    • 9





      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 '16 at 20:48






    • 3





      Though sometime system may be so full that even dpkg can not operate. But rm can be used then.

      – jarno
      Nov 5 '16 at 17:27

















    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.

    – Strifey16
    Aug 2 '12 at 16:28







    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.

    – Strifey16
    Aug 2 '12 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.

    – John S Gruber
    Aug 2 '12 at 19:42





    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.

    – John S Gruber
    Aug 2 '12 at 19:42




    2




    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.

    – Strifey16
    Aug 4 '12 at 19:13





    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.

    – Strifey16
    Aug 4 '12 at 19:13




    9




    9





    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 '16 at 20:48





    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 '16 at 20:48




    3




    3





    Though sometime system may be so full that even dpkg can not operate. But rm can be used then.

    – jarno
    Nov 5 '16 at 17:27





    Though sometime system may be so full that even dpkg can not operate. But rm can be used then.

    – jarno
    Nov 5 '16 at 17:27













    62














    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.






    share|improve this answer


























    • This was the most helpful for me out of all of the suggestions. Thank you very much!

      – Joshua F. Rountree
      Mar 28 '15 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 '16 at 22:54
















    62














    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.






    share|improve this answer


























    • This was the most helpful for me out of all of the suggestions. Thank you very much!

      – Joshua F. Rountree
      Mar 28 '15 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 '16 at 22:54














    62












    62








    62







    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.






    share|improve this answer















    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.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Apr 27 '18 at 7:20









    ubashu

    2,37321837




    2,37321837










    answered Feb 20 '14 at 16:48









    A.G. RussellA.G. Russell

    63152




    63152













    • This was the most helpful for me out of all of the suggestions. Thank you very much!

      – Joshua F. Rountree
      Mar 28 '15 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 '16 at 22:54



















    • This was the most helpful for me out of all of the suggestions. Thank you very much!

      – Joshua F. Rountree
      Mar 28 '15 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 '16 at 22:54

















    This was the most helpful for me out of all of the suggestions. Thank you very much!

    – Joshua F. Rountree
    Mar 28 '15 at 1:53





    This was the most helpful for me out of all of the suggestions. Thank you very much!

    – Joshua F. Rountree
    Mar 28 '15 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 '16 at 22:54





    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 '16 at 22:54











    19














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



    sudo dpkg -r linux-image-3.2.0-29-generic





    share|improve this answer
























    • 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 '15 at 13:09








    • 2





      @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 '17 at 10:27
















    19














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



    sudo dpkg -r linux-image-3.2.0-29-generic





    share|improve this answer
























    • 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 '15 at 13:09








    • 2





      @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 '17 at 10:27














    19












    19








    19







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



    sudo dpkg -r linux-image-3.2.0-29-generic





    share|improve this answer













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



    sudo dpkg -r linux-image-3.2.0-29-generic






    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Apr 8 '14 at 14:38









    psusipsusi

    31.1k15088




    31.1k15088













    • 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 '15 at 13:09








    • 2





      @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 '17 at 10:27



















    • 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 '15 at 13:09








    • 2





      @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 '17 at 10:27

















    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 '15 at 13:09







    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 '15 at 13:09






    2




    2





    @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 '17 at 10:27





    @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 '17 at 10:27











    9














    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





    share|improve this answer






























      9














      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





      share|improve this answer




























        9












        9








        9







        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





        share|improve this answer















        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






        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited May 24 '18 at 3:04









        ubashu

        2,37321837




        2,37321837










        answered Oct 24 '12 at 13:56









        mreitermreiter

        9111




        9111























            3














            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






            share|improve this answer





















            • 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 '16 at 4:34
















            3














            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






            share|improve this answer





















            • 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 '16 at 4:34














            3












            3








            3







            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






            share|improve this answer















            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







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Apr 27 '18 at 7:15









            ubashu

            2,37321837




            2,37321837










            answered Nov 22 '15 at 17:33









            SamerSamer

            1791314




            1791314








            • 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 '16 at 4:34














            • 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 '16 at 4:34








            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 '16 at 4:34





            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 '16 at 4:34











            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





            share|improve this answer


























            • What does /var/tmp have to do with old kernels? And it is not always safe to delete everything in /var/tmp...

              – ubashu
              Apr 27 '18 at 7:09


















            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





            share|improve this answer


























            • What does /var/tmp have to do with old kernels? And it is not always safe to delete everything in /var/tmp...

              – ubashu
              Apr 27 '18 at 7:09
















            2












            2








            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





            share|improve this answer















            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






            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Apr 27 '18 at 7:09









            ubashu

            2,37321837




            2,37321837










            answered Nov 6 '17 at 9:29









            TertiusTertius

            211




            211













            • What does /var/tmp have to do with old kernels? And it is not always safe to delete everything in /var/tmp...

              – ubashu
              Apr 27 '18 at 7:09





















            • What does /var/tmp have to do with old kernels? And it is not always safe to delete everything in /var/tmp...

              – ubashu
              Apr 27 '18 at 7:09



















            What does /var/tmp have to do with old kernels? And it is not always safe to delete everything in /var/tmp...

            – ubashu
            Apr 27 '18 at 7:09







            What does /var/tmp have to do with old kernels? And it is not always safe to delete everything in /var/tmp...

            – ubashu
            Apr 27 '18 at 7:09













            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.






            share|improve this answer





















            • 5





              The home folder is not in /boot

              – Thorbjørn Ravn Andersen
              May 17 '13 at 8:05
















            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.






            share|improve this answer





















            • 5





              The home folder is not in /boot

              – Thorbjørn Ravn Andersen
              May 17 '13 at 8:05














            2












            2








            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.






            share|improve this answer















            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.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Apr 27 '18 at 7:15









            ubashu

            2,37321837




            2,37321837










            answered Aug 2 '12 at 15:20









            hexafractionhexafraction

            16.2k105486




            16.2k105486








            • 5





              The home folder is not in /boot

              – Thorbjørn Ravn Andersen
              May 17 '13 at 8:05














            • 5





              The home folder is not in /boot

              – Thorbjørn Ravn Andersen
              May 17 '13 at 8:05








            5




            5





            The home folder is not in /boot

            – Thorbjørn Ravn Andersen
            May 17 '13 at 8:05





            The home folder is not in /boot

            – Thorbjørn Ravn Andersen
            May 17 '13 at 8:05











            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.






            share|improve this answer



















            • 1





              E.g. on a (text-only) server, there is no Synaptic. So not really a viable solution for servers.

              – nerdoc
              Aug 31 '17 at 20:41
















            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.






            share|improve this answer



















            • 1





              E.g. on a (text-only) server, there is no Synaptic. So not really a viable solution for servers.

              – nerdoc
              Aug 31 '17 at 20:41














            1












            1








            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.






            share|improve this answer













            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.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Aug 3 '12 at 2:39









            WegkoWegko

            654




            654








            • 1





              E.g. on a (text-only) server, there is no Synaptic. So not really a viable solution for servers.

              – nerdoc
              Aug 31 '17 at 20:41














            • 1





              E.g. on a (text-only) server, there is no Synaptic. So not really a viable solution for servers.

              – nerdoc
              Aug 31 '17 at 20:41








            1




            1





            E.g. on a (text-only) server, there is no Synaptic. So not really a viable solution for servers.

            – nerdoc
            Aug 31 '17 at 20:41





            E.g. on a (text-only) server, there is no Synaptic. So not really a viable solution for servers.

            – nerdoc
            Aug 31 '17 at 20:41











            1














            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.






            share|improve this answer


























            • 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.

              – machineaddict
              Sep 24 '18 at 14:16
















            1














            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.






            share|improve this answer


























            • 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.

              – machineaddict
              Sep 24 '18 at 14:16














            1












            1








            1







            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.






            share|improve this answer















            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.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Apr 27 '18 at 7:08









            ubashu

            2,37321837




            2,37321837










            answered Apr 3 '17 at 23:29









            Matthew SwansonMatthew Swanson

            114




            114













            • 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.

              – machineaddict
              Sep 24 '18 at 14:16



















            • 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.

              – machineaddict
              Sep 24 '18 at 14:16

















            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.

            – machineaddict
            Sep 24 '18 at 14:16





            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.

            – machineaddict
            Sep 24 '18 at 14:16











            0














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






            share|improve this answer



















            • 2





              Did you have 100% disk space /boot usage?

              – ubashu
              Apr 27 '18 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 '18 at 11:26
















            0














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






            share|improve this answer



















            • 2





              Did you have 100% disk space /boot usage?

              – ubashu
              Apr 27 '18 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 '18 at 11:26














            0












            0








            0







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






            share|improve this answer













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







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Apr 26 '18 at 8:26









            forzagreenforzagreen

            1093




            1093








            • 2





              Did you have 100% disk space /boot usage?

              – ubashu
              Apr 27 '18 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 '18 at 11:26














            • 2





              Did you have 100% disk space /boot usage?

              – ubashu
              Apr 27 '18 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 '18 at 11:26








            2




            2





            Did you have 100% disk space /boot usage?

            – ubashu
            Apr 27 '18 at 6:58





            Did you have 100% disk space /boot usage?

            – ubashu
            Apr 27 '18 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 '18 at 11:26





            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 '18 at 11:26











            0














            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






            share|improve this answer


























            • what does sudo dpkg-reconfigure -a this do? On Ubuntu 16 its says unknown option -a

              – Shivam Kotwalia
              Nov 28 '17 at 7:59











            • 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 '18 at 5:52













            • @muru I just posted it because it did the trick, for me :D

              – Ardi Nusawan
              Jan 23 '18 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 '18 at 14:08











            • @muru oh ok got it :D

              – Ardi Nusawan
              Jan 23 '18 at 14:10
















            0














            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






            share|improve this answer


























            • what does sudo dpkg-reconfigure -a this do? On Ubuntu 16 its says unknown option -a

              – Shivam Kotwalia
              Nov 28 '17 at 7:59











            • 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 '18 at 5:52













            • @muru I just posted it because it did the trick, for me :D

              – Ardi Nusawan
              Jan 23 '18 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 '18 at 14:08











            • @muru oh ok got it :D

              – Ardi Nusawan
              Jan 23 '18 at 14:10














            0












            0








            0







            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






            share|improve this answer















            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







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Apr 27 '18 at 7:13









            ubashu

            2,37321837




            2,37321837










            answered Feb 15 '17 at 18:41









            Ardi NusawanArdi Nusawan

            172




            172













            • what does sudo dpkg-reconfigure -a this do? On Ubuntu 16 its says unknown option -a

              – Shivam Kotwalia
              Nov 28 '17 at 7:59











            • 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 '18 at 5:52













            • @muru I just posted it because it did the trick, for me :D

              – Ardi Nusawan
              Jan 23 '18 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 '18 at 14:08











            • @muru oh ok got it :D

              – Ardi Nusawan
              Jan 23 '18 at 14:10



















            • what does sudo dpkg-reconfigure -a this do? On Ubuntu 16 its says unknown option -a

              – Shivam Kotwalia
              Nov 28 '17 at 7:59











            • 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 '18 at 5:52













            • @muru I just posted it because it did the trick, for me :D

              – Ardi Nusawan
              Jan 23 '18 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 '18 at 14:08











            • @muru oh ok got it :D

              – Ardi Nusawan
              Jan 23 '18 at 14:10

















            what does sudo dpkg-reconfigure -a this do? On Ubuntu 16 its says unknown option -a

            – Shivam Kotwalia
            Nov 28 '17 at 7:59





            what does sudo dpkg-reconfigure -a this do? On Ubuntu 16 its says unknown option -a

            – Shivam Kotwalia
            Nov 28 '17 at 7:59













            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 '18 at 5:52







            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 '18 at 5:52















            @muru I just posted it because it did the trick, for me :D

            – Ardi Nusawan
            Jan 23 '18 at 14:06





            @muru I just posted it because it did the trick, for me :D

            – Ardi Nusawan
            Jan 23 '18 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 '18 at 14:08





            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 '18 at 14:08













            @muru oh ok got it :D

            – Ardi Nusawan
            Jan 23 '18 at 14:10





            @muru oh ok got it :D

            – Ardi Nusawan
            Jan 23 '18 at 14:10


















            draft saved

            draft discarded




















































            Thanks for contributing an answer to Ask Ubuntu!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f171209%2fmy-boot-partition-hit-100-and-now-i-cant-upgrade-cant-remove-old-kernels-to%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            How to reconfigure Docker Trusted Registry 2.x.x to use CEPH FS mount instead of NFS and other traditional...

            is 'sed' thread safe

            How to make a Squid Proxy server?