3

I have an Ubuntu 14.04 installation that I'm trying to do-release-upgrade to 16.04. When I try, I get the error

Not enough free disk space

The upgrade has aborted. The upgrade needs a total of 76.2 M free space on disk '/boot'. Please free at least an additional 58.8 M of disk space on '/boot'.

apt-get autoremove and apt-get clean did not remove any files. From web searching, it looks like the standard solution to this problem is provided by Alaa Ali's answer to this AskUbuntu question, which is to apt-get purge unused kernel images. Following this advice, I removed 41 kernel images. This did not free up any space on /boot, however.

Before apt-get purgeing the 41 images, the output of df -h was

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.9G  4.0K  3.9G   1% /dev
tmpfs           785M 1012K  784M   1% /run
/dev/sda2        47G   28G   17G  62% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
none            5.0M     0  5.0M   0% /run/lock
none            3.9G   88K  3.9G   1% /run/shm
none            100M   20K  100M   1% /run/user
/dev/sdb1       459G  121G  338G  27% /data
/dev/sda1       114M   89M   17M  85% /boot
/dev/sda4       404G   90G  295G  24% /home

After purging, the output of df -h is

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.9G  4.0K  3.9G   1% /dev
tmpfs           785M 1012K  784M   1% /run
/dev/sda2        47G   28G   17G  62% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
none            5.0M     0  5.0M   0% /run/lock
none            3.9G   88K  3.9G   1% /run/shm
none            100M   20K  100M   1% /run/user
/dev/sdb1       459G  121G  338G  27% /data
/dev/sda1       114M   89M   17M  85% /boot
/dev/sda4       404G   90G  295G  24% /home

Nothing has changed. I still get the same error when I try to do-release-upgrade.

Comparing the output of dpkg -l | grep linux-image before and after purging images confirms that the kernel images were removed.

Every answer on this that I've found has boiled down to autoremove, clean, or purging kernel images, and none of those have worked. What do I do now?

Edit: Additional Information

Here is the output of dpkg -l | grep linux-image before purging:

$ dpkg -l | grep linux-image
rc  linux-image-2.6.32-21-generic            2.6.32-21.32         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-23-generic            2.6.32-23.37         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-24-generic            2.6.32-24.43         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-25-generic            2.6.32-25.45         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-26-generic            2.6.32-26.48         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-27-generic            2.6.32-27.49         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-29-generic            2.6.32-29.58         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-30-generic            2.6.32-30.59         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-31-generic            2.6.32-31.61         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-32-generic            2.6.32-32.62         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-34-generic            2.6.32-34.77         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-37-generic            2.6.32-37.81         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-38-generic            2.6.32-38.83         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-39-generic            2.6.32-39.86         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-40-generic            2.6.32-40.87         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-41-generic            2.6.32-41.94         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-2.6.32-44-generic            2.6.32-44.98         amd64        Linux kernel image for version 2.6.32 on     x86/x86_64
rc  linux-image-3.13.0-107-generic           3.13.0-107.154       amd64        Linux kernel image for version 3.13.0 on     64 bit x86 SMP
rc  linux-image-3.13.0-116-generic           3.13.0-116.163       amd64        Linux kernel image for version 3.13.0 on     64 bit x86 SMP
rc  linux-image-3.13.0-157-generic           3.13.0-157.207       amd64        Linux kernel image for version 3.13.0 on     64 bit x86 SMP
ii  linux-image-3.13.0-164-generic           3.13.0-164.214       amd64        Linux kernel image for version 3.13.0 on     64 bit x86 SMP
ii  linux-image-3.13.0-170-generic           3.13.0-170.220       amd64        Signed kernel image generic
rc  linux-image-3.13.0-66-generic            3.13.0-66.108        amd64        Linux kernel image for version 3.13.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-32-generic             3.2.0-32.51          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-33-generic             3.2.0-33.52          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-34-generic             3.2.0-34.53          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-35-generic             3.2.0-35.55          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-36-generic             3.2.0-36.57          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-37-generic             3.2.0-37.58          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-38-generic             3.2.0-38.61          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-39-generic             3.2.0-39.62          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-40-generic             3.2.0-40.64          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-41-generic             3.2.0-41.66          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-45-generic             3.2.0-45.70          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-48-generic             3.2.0-48.74          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-49-generic             3.2.0-49.75          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-53-generic             3.2.0-53.81          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-58-generic             3.2.0-58.88          amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-88-generic             3.2.0-88.126         amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-89-generic             3.2.0-89.127         amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-3.2.0-92-generic             3.2.0-92.131         amd64        Linux kernel image for version 3.2.0 on     64 bit x86 SMP
rc  linux-image-extra-3.13.0-107-generic     3.13.0-107.154       amd64        Linux kernel extra modules for version     3.13.0 on 64 bit x86 SMP
rc  linux-image-extra-3.13.0-116-generic     3.13.0-116.163       amd64        Linux kernel extra modules for version     3.13.0 on 64 bit x86 SMP
rc  linux-image-extra-3.13.0-157-generic     3.13.0-157.207       amd64        Linux kernel extra modules for version     3.13.0 on 64 bit x86 SMP
ii  linux-image-extra-3.13.0-164-generic     3.13.0-164.214       amd64        Linux kernel extra modules for version     3.13.0 on 64 bit x86 SMP
rc  linux-image-extra-3.13.0-66-generic      3.13.0-66.108        amd64        Linux kernel extra modules for version     3.13.0 on 64 bit x86 SMP
ii  linux-image-generic                      3.13.0.170.181       amd64        Generic Linux kernel image

Here are the commands I used to purge images:

$ sudo apt-get purge linux-image-2.6.32-{21,23,24,25,26,27,29,30,31,32,34,37,38,39,40,41,44}-generic
$ sudo apt-get purge linux-image-3.2.0-{32,33,34,35,36,37,38,39,40,41,45,48,49,53,58,88,89,92}-generic
$ sudo apt-get purge linux-image-3.13.0-107-generic
$ sudo apt-get purge linux-image-3.13.0-116-generic 
$ sudo apt-get purge linux-image-extra-3.13.0-107-generic
$ sudo apt-get purge linux-image-extra-3.13.0-116-generic
$ sudo apt-get purge linux-image-3.13.0-66-generic
$ sudo apt-get purge linux-image-extra-3.13.0-66-generic

Here is the output of dpkg -l | grep linux-image after running the above purge commands:

$ dpkg -l | grep linux-image
rc  linux-image-3.13.0-157-generic           3.13.0-157.207   amd64        Linux kernel image for version 3.13.0 on 64 bit x86 SMP
ii  linux-image-3.13.0-164-generic           3.13.0-164.214   amd64        Linux kernel image for version 3.13.0 on 64 bit x86 SMP
ii  linux-image-3.13.0-170-generic           3.13.0-170.220   amd64        Signed kernel image generic
rc  linux-image-extra-3.13.0-157-generic     3.13.0-157.207   amd64        Linux kernel extra modules for version 3.13.0 on 64 bit     x86 SMP
ii  linux-image-extra-3.13.0-164-generic     3.13.0-164.214   amd64        Linux kernel extra modules for version 3.13.0 on 64 bit     x86 SMP
ii  linux-image-generic                      3.13.0.170.181   amd64        Generic Linux kernel image

Here are the current contents of /boot:

$ ls -l /boot
total 81817
-rw-r--r-- 1 root root  1169147 Dec  5  2018 abi-3.13.0-164-generic
-rw-r--r-- 1 root root   166221 Dec  5  2018 config-3.13.0-164-generic
-rw-r--r-- 1 root root   166221 May  9 09:35 config-3.13.0-170-generic
drwxr-xr-x 5 root root     1024 Jul 19 14:43 grub
-rw-r--r-- 1 root root 31803728 Jul  9 13:28 initrd.img-3.13.0-164-generic
-rw-r--r-- 1 root root 31804631 Jul  9 13:28 initrd.img-3.13.0-170-generic
drwx------ 2 root root    12288 Jul 22  2010 lost+found
-rw-r--r-- 1 root root      254 Dec  5  2018 retpoline-3.13.0-164-generic
-rw------- 1 root root  3417774 Dec  5  2018 System.map-3.13.0-164-generic
-rw------- 1 root root  3418683 May  9 09:35 System.map-3.13.0-170-generic
-rw------- 1 root root  5905712 Dec  5  2018 vmlinuz-3.13.0-164-generic
-rw------- 1 root root  5909496 May 14 15:03 vmlinuz-3.13.0-170-generic

Here is uname -r:

$ uname -r
3.13.0-170-generic

Edit: Summary

I've managed to get /boot to have 58M available by removing one more kernel image. do-release-upgrade needs 77M, so I still need around ~20M.

The remaining kernel image (the one that I'm currently using) is 31M. Beyond that, everything else in /boot totals ~15.9M. There doesn't seem to be a way to free enough space to run do-release-upgrade without deleting my current kernel image. Does anyone see anything I'm missing?

Data to tally up disk space:

$ sudo du -h -d 1 /boot/
12K /boot/lost+found
6.7M    /boot/grub
47M /boot/
$ ls -lh /boot
total 40M
-rw-r--r-- 1 root root 163K May  9 09:35 config-3.13.0-170-generic
drwxr-xr-x 5 root root 1.0K Jul 23 13:41 grub
-rw-r--r-- 1 root root  31M Jul  9 13:28 initrd.img-3.13.0-170-generic
drwx------ 2 root root  12K Jul 22  2010 lost+found
-rw------- 1 root root 3.3M May  9 09:35 System.map-3.13.0-170-generic
-rw------- 1 root root 5.7M May 14 15:03 vmlinuz-3.13.0-170-generic

Edit: Resolution

It seems clear that I'm not capable of resolving this issue. Thank you to everyone who kindly offered information and advice!

Borea Deitz
  • 213
  • 1
    Seems impossible to have 41 kernels in a mere 114 MB, and also impossible for their removal to free no space at all. Perhaps you removed something different, or you looked at a list of already-removed packages, or something else. It's an important difference - it means you're not actually doing what you intended to do. Our help will be of limited use until you can successfully list the kernels actually eligible for removal, and really remove them. Please edit your question to show the complete output of ls -l /boot – user535733 Jul 23 '19 at 15:32
  • @user535733 Much about this situation seems implausible, so I'm sure I'm missing something. I just can't tell what. I've added the output you asked for as well as other data that might be helpful. – Borea Deitz Jul 23 '19 at 17:22
  • Look at your ls -l /boot. That's what is actually taking up space. Now you have only two kernels installed: -164 and -170. You cannot remove -170, it's what you are currently running. So remove -164: Try sudo apt remove linux-image-3.13.0-164-generic. It will automatically remove -164-extra, also. After that, look at your space available (df -h) again. – user535733 Jul 23 '19 at 17:30
  • Quick tip: When you ran dpkg -l, and you saw all those old kernels, everything marked "rc" was already removed. Only the "ii" packages are installed and taking up space. – user535733 Jul 23 '19 at 17:32
  • what makes a lost+found folder in boot? sudo rm -rf /boot/lost+found or mv it to another folder sudo mv /boot/lost+found $HOME – nobody Jul 23 '19 at 17:38
  • @user535733 Thanks for the tip, I didn't realize that. I removed the '164' image as you suggested; /boot now has 58M free. do-release-upgrade says in needs 76.2M. Do you see a good way to get that extra ~20M? – Borea Deitz Jul 23 '19 at 17:50
  • @nobody I'm not sure, but the folder is empty. I'm going to leave it for now, since removing it won't free up any meaningful space. – Borea Deitz Jul 23 '19 at 17:52
  • There has to be a lost+found in each mounted directory (in root of mountpoint) - don't remove it, Bot if there are any old files in /boot/lost-found, you can delete them. They are leftovers from earlier fsck's (file systm checks), – Soren A Jul 23 '19 at 18:10
  • What are the output of `df -h' after purging the old kernels ? That shouldhaveleft lots of spacein /boot. – Soren A Jul 23 '19 at 18:11
  • sudo apt purge $(dpkg -l | egrep '^rc' | awk '{print $2}') – nobody Jul 23 '19 at 18:21
  • @SorenA It's exactly the same as before, except the /boot line is /dev/sda1 114M 48M 58M 46% /boot. 58M free now, but I need 77M. – Borea Deitz Jul 23 '19 at 18:29
  • @karel It's a related question, but not a duplicate. I wasn't having the same error as the asker there, and none of the answers to that question are helpful to me. – Borea Deitz Jul 23 '19 at 18:51
  • The basic problem is your /boot partition is really too small. What I'd do if I were you is rm the initrd file, but it's risky because then you can't reboot on the old kernel if the upgrade fails and the new kernel is not properly installed (hence I'm not posting this as an answer). Really, the only proper thing to do is do a fresh install with a larger /boot partition (if you even need a separate /boot partition at all). – fkraiem Jul 23 '19 at 19:32

3 Answers3

4

The simplest way, when you aren't booting with EFI, is to move /boot to / where you have tons of free space.

From: Arch Linux How to move /boot to /

Boot from a live distro, mount the partition containing / to /mnt/main the partition containing /boot to /mnt/boot then copy /mnt/boot to /mnt/main.

Then remove the "/boot" entry from your /etc/fstab, (arch-)chroot into Arch & reinstall GRUB.

Rather than removing /boot entry though I would comment it out with #.

Rather than chroot and reinstall GRUB, I would use boot-repair.

If you do not have physical access to your server, have a look here

Fabby
  • 34,259
WinEunuuchs2Unix
  • 102,282
  • This seems like a good approach and a good answer. Thank you for posting it. My situation has one more difficulty, though: I don't have physical access to the server, so booting from a live distro is out. – Borea Deitz Jul 23 '19 at 20:41
  • Someone else gets credit for that answer in Arch Linux. It should be possible to rename existing /boot to /boot2 on sda1 and cp it to /boot on sda2 without having to use Live USB. – WinEunuuchs2Unix Jul 23 '19 at 20:55
  • 1
    @BoreaDeitz Not true. See updated answer or have a look here. Also: don't forget to accept or upvote any answers that you found useful! ;-) – Fabby Jul 24 '19 at 06:57
  • @Fabby Thanks for the link, I did have a look at it. Unfortunately the answer there is too far over my head for me to work on it at the moment. – Borea Deitz Jul 24 '19 at 13:54
  • @BoreaDeitz Before doing any of above on production server, try it on a test laptop first. – WinEunuuchs2Unix Jul 24 '19 at 14:00
1

Moving /boot to the root partition can be done without a live system, as follows. (Every step should be self-explanatory, but note that I reinstall the GRUB and kernel packages instead of just copying files.)

Warning: do not forget any step, especially grub-install and update-grub, lest your system become unbootable.

firas@ubuntu:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            2.0G  4.0K  2.0G   1% /dev
tmpfs           396M  420K  395M   1% /run
/dev/sda2       9.1G  1.2G  7.5G  14% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
none            5.0M  8.0K  5.0M   1% /run/lock
none            2.0G     0  2.0G   0% /run/shm
none            100M     0  100M   0% /run/user
/dev/sda1       464M   38M  398M   9% /boot

firas@ubuntu:~$ ls /boot
config-3.13.0-170-generic  initrd.img-3.13.0-170-generic  System.map-3.13.0-170-generic
grub                       lost+found                     vmlinuz-3.13.0-170-generic
firas@ubuntu:~$ sudo umount /boot
firas@ubuntu:~$ ls /boot
firas@ubuntu:~$ grep boot /etc/fstab
# /boot was on /dev/sda1 during installation
#UUID=9e6d0006-a9c2-4d0d-9b8a-615ffd9f533a /boot           ext4    defaults        0       2

firas@ubuntu:~$ apt list --installed | grep grub

WARNING: apt does not have a stable CLI interface yet. Use with caution in scripts.

grub-common/trusty-updates,now 2.02~beta2-9ubuntu1.17 amd64 [installed]
grub-gfxpayload-lists/trusty,now 0.6 amd64 [installed,automatic]
grub-pc/trusty-updates,now 2.02~beta2-9ubuntu1.17 amd64 [installed]
grub-pc-bin/trusty-updates,now 2.02~beta2-9ubuntu1.17 amd64 [installed,automatic]
grub2-common/trusty-updates,now 2.02~beta2-9ubuntu1.17 amd64 [installed,automatic]

firas@ubuntu:~$ sudo apt-get install --reinstall grub-common grub-gfxpayload-lists grub-pc grub-pc-bin grub2-common
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 to upgrade, 0 to newly install, 5 reinstalled, 0 to remove and 0 not to upgrade.
Need to get 0 B/3,241 kB of archives.
After this operation, 0 B of additional disk space will be used.
Preconfiguring packages ...
(Reading database ... 54436 files and directories currently installed.)
Preparing to unpack .../grub-common_2.02~beta2-9ubuntu1.17_amd64.deb ...
Unpacking grub-common (2.02~beta2-9ubuntu1.17) over (2.02~beta2-9ubuntu1.17) ...
Preparing to unpack .../grub-gfxpayload-lists_0.6_amd64.deb ...
Unpacking grub-gfxpayload-lists (0.6) over (0.6) ...
Preparing to unpack .../grub-pc_2.02~beta2-9ubuntu1.17_amd64.deb ...
Unpacking grub-pc (2.02~beta2-9ubuntu1.17) over (2.02~beta2-9ubuntu1.17) ...
Preparing to unpack .../grub-pc-bin_2.02~beta2-9ubuntu1.17_amd64.deb ...
Unpacking grub-pc-bin (2.02~beta2-9ubuntu1.17) over (2.02~beta2-9ubuntu1.17) ...
Preparing to unpack .../grub2-common_2.02~beta2-9ubuntu1.17_amd64.deb ...
Unpacking grub2-common (2.02~beta2-9ubuntu1.17) over (2.02~beta2-9ubuntu1.17) ...
Processing triggers for ureadahead (0.100.0-16) ...
Processing triggers for man-db (2.6.7.1-1ubuntu1) ...
Processing triggers for install-info (5.2.0.dfsg.1-2) ...
Setting up grub-common (2.02~beta2-9ubuntu1.17) ...
Setting up grub2-common (2.02~beta2-9ubuntu1.17) ...
Setting up grub-pc-bin (2.02~beta2-9ubuntu1.17) ...
Setting up grub-gfxpayload-lists (0.6) ...
Setting up grub-pc (2.02~beta2-9ubuntu1.17) ...

firas@ubuntu:~$ sudo grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

firas@ubuntu:~$ apt list --installed | grep linux

WARNING: apt does not have a stable CLI interface yet. Use with caution in scripts.

libselinux1/trusty-updates,now 2.2.2-1ubuntu0.1 amd64 [installed]
linux-base/trusty-updates,trusty-security,now 4.5ubuntu1~14.04.1 all [installed,automatic]
linux-firmware/trusty-updates,trusty-security,now 1.127.24 all [installed,automatic]
linux-generic/trusty-updates,trusty-security,now 3.13.0.170.181 amd64 [installed]
linux-headers-3.13.0-170/trusty-updates,trusty-security,now 3.13.0-170.220 all [installed,automatic]
linux-headers-3.13.0-170-generic/trusty-updates,trusty-security,now 3.13.0-170.220 amd64 [installed,automatic]
linux-headers-generic/trusty-updates,trusty-security,now 3.13.0.170.181 amd64 [installed]
linux-image-3.13.0-170-generic/trusty-updates,trusty-security,now 3.13.0-170.220 amd64 [installed,automatic]
linux-image-generic/trusty-updates,trusty-security,now 3.13.0.170.181 amd64 [installed,automatic]
linux-modules-3.13.0-170-generic/trusty-updates,trusty-security,now 3.13.0-170.220 amd64 [installed,automatic]
linux-modules-extra-3.13.0-170-generic/trusty-updates,trusty-security,now 3.13.0-170.220 amd64 [installed,automatic]
util-linux/trusty-updates,now 2.20.1-5.1ubuntu20.9 amd64 [installed]

firas@ubuntu:~$ sudo apt-get install --reinstall linux-image-3.13.0-170-generic linux-modules-3.13.0-170-generic linux-modules-extra-3.13.0-170-generic
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 to upgrade, 0 to newly install, 3 reinstalled, 0 to remove and 0 not to upgrade.
Need to get 0 B/50.5 MB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 54436 files and directories currently installed.)
Preparing to unpack .../linux-image-3.13.0-170-generic_3.13.0-170.220_amd64.deb ...
Unpacking linux-image-3.13.0-170-generic (3.13.0-170.220) over (3.13.0-170.220) ...
Preparing to unpack .../linux-modules-3.13.0-170-generic_3.13.0-170.220_amd64.deb ...
Unpacking linux-modules-3.13.0-170-generic (3.13.0-170.220) over (3.13.0-170.220) ...
Preparing to unpack .../linux-modules-extra-3.13.0-170-generic_3.13.0-170.220_amd64.deb ...
Unpacking linux-modules-extra-3.13.0-170-generic (3.13.0-170.220) over (3.13.0-170.220) ...
Setting up linux-modules-3.13.0-170-generic (3.13.0-170.220) ...
Setting up linux-image-3.13.0-170-generic (3.13.0-170.220) ...
Setting up linux-modules-extra-3.13.0-170-generic (3.13.0-170.220) ...
Processing triggers for linux-image-3.13.0-170-generic (3.13.0-170.220) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-3.13.0-170-generic

firas@ubuntu:~$ sudo update-grub
Generating grub configuration file ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Found linux image: /boot/vmlinuz-3.13.0-170-generic
Found initrd image: /boot/initrd.img-3.13.0-170-generic
done
firas@ubuntu:~$ sudo reboot
fkraiem
  • 12,555
  • 4
  • 35
  • 40
  • Thank you very much for your effort, this is an excellent answer. In my experience with Ubuntu, I've never followed a procedure like this more than three lines long and had it not fail with some sort of error. If that happens while I'm doing this, then I lose the system, and so do all of the other people who use it. So, I'm not willing try it. I'll update my question to acknowledge defeat. – Borea Deitz Jul 24 '19 at 14:07
0

I once had a similar situation with a lot of kernel files that were carried over from previous upgrades.

First, you only need one kernel for the system to work. Uninstall all the others including accompanying header and extra files.

Next, if this still does not clear enough space, you may manually remove all remaining files from /boot from a terminal leaving only the files associated with the one kernel in use.

See this question

To Do
  • 15,502
  • Thanks for answering! I know the original question got a bit long with all of the edits, but buried in there towards the end you'll find that the solution you've given still wouldn't leave /boot enough space for the upgrade. The problem shifted to "how to expand a partition over SSH," for which there aren't any sufficiently safe options for me. – Borea Deitz Jul 24 '19 at 17:46