0

Well this question is asked often - however the solution seems not be so clear and does not really work for me.

$ df
Filesystem               1k-blocks      Used  Available  Use% Mounted on
/dev/sda5                   184307    173269          0  100% /boot
/dev/sda6                  4673664   2926312    1486900   67% /home


$ dpkg -l | tail -n +6 | grep -E 'linux-image-[0-9]+' | grep -Fv $(uname -r)

pi  linux-image-4.4.0-21-generic                    4.4.0-21.37                                amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
ii  linux-image-4.4.0-22-generic                    4.4.0-22.40                                amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
iF  linux-image-4.4.0-28-generic                    4.4.0-28.47                                amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
iF  linux-image-4.4.0-31-generic                    4.4.0-31.50                                amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP

And this is the best one:

$ sudo apt-get purge linux-image-extra-4.4.0-36-generic

Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Probieren Sie »apt-get -f install«, um dies zu korrigieren:
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 linux-image-extra-4.4.0-34-generic : Hängt ab von: linux-image-4.4.0-34-generic soll aber nicht installiert werden
 linux-image-generic : Hängt ab von: linux-image-4.4.0-36-generic soll aber nicht installiert werden
                       Hängt ab von: linux-image-extra-4.4.0-36-generic soll aber nicht installiert werden
E: Unerfüllte Abhängigkeiten. Versuchen Sie »apt-get -f install« ohne Angabe eines Pakets (oder geben Sie eine Lösung an)

Somehow the 4.4.0-36 seems to be installed but it isn't. I even cannot brainwash the package manager.

I know I SHALL NOT cd /boot;rm -f ........ in order to confuse the masterbrain not even more but I see no other way then to help itself to get clean.

My question now is the following:

Can I sudo rm -f /boot/somebigfiles;sudo touch /boot/somebigfiles in order to create some working space on /boot?

How to fool the package manager so he thinks the stuff is installed and can clean itself with all the nice apt-get clean/autoclean and other apt commands?

Thiago Rider Augusto
  • 1,640
dhd
  • 1
  • https://help.ubuntu.com/community/Lubuntu/Documentation/RemoveOldKernels Some have had to manually remove one kernel to make space. But since still listed in dpkg you may want to reinstall it and purge correctly, so all related files and settings are also removed. – oldfred Sep 13 '16 at 18:44
  • Tell us what you ever tried to solve the problem and what gone wrong. – Thiago Rider Augusto Sep 13 '16 at 19:28

4 Answers4

0

Maybe not the easiest solution but here is how I would try to resolve the issue.

Get a USB stick bigger than your /boot partition Copy the content of /boot on it Then adjust /etc/fstab to mount the usb-stick to /boot on next reboot Reboot Clean your things, upgrade Then copy the content /boot (usb-stick) to older /boot (that you can mount on say /boot1) When done, edit /etc/fstab again to mount the /boot partition instead of the usb-stick and reboot

sebastienvg
  • 221
0

What you can do to clean up space on the boot partition without confusing you package manager is to keep the files but remove the contents of them.

for example:

echo "" > /boot/vmlinuz-old-version-old-you-want-to-remove
echo "" > /boot/initrd-old-version-old-you-want-to-remove

this will reclaim the used space but leaving the file in place empty.

Since apt seems stuck in a broken state you should run

apt-get install -f

after giving some room in /boot/ with the examples above

a more long term solution is to boot on Ubuntu of a USB stick and simply resize your boot partition with gparted so it will fit more versions in the future.

tomodachi
  • 14,832
0

I recently ran into this after failing to cleanup old kernels. The approach I used was to cd to /boot and delete a couple of old kernels. If you haven't rebooted in a while you need to ensure that you don't remove the kernel you currently are using. The following commands list files that could potentially be removed or truncated relatively safely. Files at the top of the list are more likely to be used. 

uname -r
cd /boot 
ls -1t *-* | grep -v $(uname -r)

This what it looks like when I run it now. The files for the 4.4.0-34-generic release are a good candidate fro removal.

root@ubuntu:~# uname -r
4.4.0-31-generic
root@ubuntu:~# cd /boot
root@ubuntu:/etc/grub.d$ cd /boot
root@apollo:/boot# ls -1t *-* | grep -v $(uname -r)
initrd.img-4.4.0-34-generic
abi-4.4.0-36-generic
config-4.4.0-36-generic
System.map-4.4.0-36-generic
vmlinuz-4.4.0-36-generic
abi-4.4.0-34-generic
config-4.4.0-34-generic
System.map-4.4.0-34-generic
vmlinuz-4.4.0-34-generic
initrd.img-4.2.0-35-generic
abi-4.2.0-35-generic
config-4.2.0-35-generic
System.map-4.2.0-35-generic
vmlinuz-4.2.0-35-generic

The package manager did not get overly upset that I had removed the kernels. The removal scripts are reasonably tolerant of missing files. You can truncate files with a command like > vmlinuz-4.4.0-34-generic. There is no requirement to provide a command be before the > redirection.

Once you have make space the command dpkg --configure -a should help you cleanup.

BillThor
  • 4,698
0

The approach worked. I removed the files which I did not need (by a backup copy) AND I created empty files instead to calm the package manager.let's call them the "unwanted kernels" Then I let the package Manger apt-get fix himself with an only 50% filled boot partition. Then I purged the unwanted kernels which meant for the package manager to purge empty files. Well he did not complain ;-)

Apt-get is clean now, /boot down to 50%.

dhd
  • 1