No room on /boot for updates

Support & Help Requests Raspberry Pi
1

When I run Software Updater, it tells me that there is "Not enough free disk space. The upgrade needs a total of 48.2 M free space on disk ‘/boot’. Please free at least an additional 3,424 k of disk space on ‘/boot’. Empty your trash and remove temporary packages of former installations using ‘sudo apt-get clean’. "

Running the suggested “sudo apt-get clean” produces no output and no change in the behavior of Software Updater. Another suggestion was to run “sudo apt autoremove --purge” – this also made no difference, although it did remove a handful of other packages.

Various ubuntu software sites suggest that the problem is that old kernels should be removed, but all the instructions there refer to “linux-image” packages that should be removed via Synaptic. My system has no “linux-image” packages listed by Synaptic.

When I run “uname -r” in a terminal window, I get “4.4.26-v7+” as the output. Running “ls -ls /boot” shows

  16 -rwxr-xr-x 1 root root   14010 Oct 24 17:50 bcm2708-rpi-b.dtb
  16 -rwxr-xr-x 1 root root   14273 Oct 24 17:50 bcm2708-rpi-b-plus.dtb
  16 -rwxr-xr-x 1 root root   13964 Oct 24 17:50 bcm2708-rpi-cm.dtb
  16 -rwxr-xr-x 1 root root   15356 Oct 24 17:50 bcm2709-rpi-2-b.dtb
  16 -rwxr-xr-x 1 root root   15992 Oct 24 17:50 bcm2710-rpi-3-b.dtb
  16 -rwxr-xr-x 1 root root   15350 Oct 24 17:50 bcm2710-rpi-cm3.dtb
  24 -rwxr-xr-x 1 root root   17932 Oct 24 17:50 bootcode.bin
   8 -rwxr-xr-x 1 root root     110 Apr 21  2016 cmdline.txt
  40 -rwxr-xr-x 1 root root   36155 Oct 24 09:51 config.txt
  24 -rwxr-xr-x 1 root root   18693 Mar 15  2016 COPYING.linux
   8 -rwxr-xr-x 1 root root    2525 Oct 24 17:50 fixup_cd.dat
   8 -rwxr-xr-x 1 root root    6621 Oct 24 17:50 fixup.dat
  16 -rwxr-xr-x 1 root root    9744 Oct 24 17:50 fixup_db.dat
  16 -rwxr-xr-x 1 root root    9744 Oct 24 17:50 fixup_x.dat
4136 -rwxr-xr-x 1 root root 4229336 Oct 24 17:50 kernel7.img
4032 -rwxr-xr-x 1 root root 4127640 Oct 24 17:50 kernel.img
   8 -rwxr-xr-x 1 root root    1494 Mar 15  2016 LICENCE.broadcom
  16 drwxr-xr-x 2 root root   16384 Oct 16 11:49 overlays
 624 -rwxr-xr-x 1 root root  633508 Oct 24 17:50 start_cd.elf
4840 -rwxr-xr-x 1 root root 4949060 Oct 24 17:50 start_db.elf
2752 -rwxr-xr-x 1 root root 2816836 Oct 24 17:50 start.elf
3816 -rwxr-xr-x 1 root root 3899492 Oct 24 17:50 start_x.elf

Can any of these files be safely removed? Is there some Raspberry-specific naming of the kernels that I can use in Synaptic to find one to remove?

Thanks for your help.

1 Like
2

Hi @pdtyma,

have you tried “Bleachbit”?:

3

Have you tried running:

sudo apt autoremove

?

1 Like
4

My question was what file(s) – specifically kernel images no longer in use – could I safely remove. Unless Bleachbit has that knowledge, it won’t be useful. I doubt that it arbitrarily decides that kernel images are unimportant.

5

Another responder asked whether I had run “sudo apt autoremove” – yes, and to no effect.

But I managed to find a way to get past the original problem of having insufficient space in /boot to support system updates.

I did a work-around as follows. The kernel-image files themselves are used only at boot time: the image is loaded into RAM and executed. While it is running, the file itself will no longer be used, until the next boot. So it should be safe to move one of the images temporarily, perform the update, and restore the image to /boot. I inspected config.txt to see if a named image file was being invoked at boot; the kernel-image description was commented out. That means the system uses the default “kernel.img” at boot. I moved “kernel7.img” to /tmp, which provided enough space in /boot to allow updates to be done. After successful update, I returned “kernel7.img” to /boot. No problems since.

A longer-term solution would be to take the SD card out, put it into a USB reader attached to another system, and use gparted to enlarge the /boot partition. (I would have to first reduce the size of the other partition [root], and then assign the freed-up space to the /boot partition.)

Seems rather drastic just to do a simple maintenance task of removing defunct kernel images.

I also found in /lib/modules some evidence of six kernel images having been on the machine at one point or other. Makes me wonder if rpi-update is automagically doing some of the kernel-image maintenance for me – like keeping just the last two kernel images in /boot. That would, of course, be useful; but a little documentation to that effect would go a long way. And it still doesn’t solve the problem of having the distro set up a /boot partition that soon ends up being too small to accommodate ordinary maintenance.

Thanks to all for their assistance.

2 Likes
6

Ubuntu Cleaner might be more useful for cleaning old kernels?:

Ubuntu Cleaner_009.jpg902×535 87.3 KB

7

Thanks for the suggestion. My hunch is that Ubuntu Cleaner is aimed at platforms other than the Raspberry Pi, which currently has idiosyncratic procedures for kernel updating. Ubuntu Cleaner probably does the “linux-image” tricks that work everywhere else and not on the Pi.

My kingdom for some Pi-specific documentation on kernel-maintenance tool behaviors. All I have so far is “only use rpi-update” in the welcome window. I just get the sound of crickets when I try “man rpi-update”.

1 Like
8

Perhaps this link may be of some assistance -

9

Did you copy the right link? I ask because I see nothing kernel related :confused:

10

It was meant to be another site to post questions concerning the raspberry pi, not specific to the lack of /boot space.

11

@ptdyma - I don’t see anything redundant in that original listing, but you haven’t shown the space use/left in /boot (df -h): I have 45M free of the filesystem 60M.
Perhaps there is something which would show if you used ls -al /boot to show all the files.
Also, there might be something in the /boot/overlays/ files

12

I too have this problem. uname -r gives 4.4.19-v7 as the answer. I currently have no way to fix this and provide enough space for the update. Help would be appreciated

13

What were the results of dandnsmith suggestions?

Not sure what works with ARM, but on a standard install:

sudo apt autoremove --purge

Just thought of something else that could list the installed kernels.

dpkg -l linux-* | awk '/^ii/{ print $2}' | grep -v -e `uname -r | cut -f1,2 -d"-"`
14

@pdtyma, I recently installed Ubuntu BSP kernel on a Pine A64 board (2GB). This board has a similar ARM CPU to the Pi. An image was created by a contributor to the Pine64 forum called Longsleep. This is based on the BSP kernel. After resizing the filing system and running a script to install the Mate desktop, I tried to run Software Updater from the System/Administration menu. I got the same message about freeing space on /boot.

This thread, which I started on forum.pine64.org asked about this problem. There were no previous kernels installed. This was fresh install. The answer given by the forum member MarkHaysHarris777 solved my problem. This may work for the Pi as well. See forum thread: http://forum.pine64.org/showthread.php?tid=3202

Let us know here if this works as I have a number of Pi boards.

1 Like
15

The software updater install error message says that the upgrade requires 48.2M free space on /boot. There is 45M available on /boot. How can an upgrade take up more than twice the space of the installed system?
frank@RaspPi:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 30G 14G 16G 47% /
devtmpfs 459M 0 459M 0% /dev
tmpfs 463M 35M 429M 8% /dev/shm
tmpfs 463M 6.8M 457M 2% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 463M 0 463M 0% /sys/fs/cgroup
/dev/mmcblk0p1 64M 20M 45M 32% /boot
tmpfs 93M 40K 93M 1% /run/user/1000
frank@RaspPi:~$
The error message asks to free up space, but is this the real problem? Only 6.9M is being downloaded!

16

Try ‘sudo apt update && sudo apt upgrade’, then ‘sudo rpi-update’ (without quotes) and reboot.

I have a similar problem with the software updater, but using the command line works for me. You could also try resizing the /boot partition (and shrinking /root) using gparted on a linux machine.

1 Like
17

I, too, have a lot of free space on /boot – at least 45 MB. The problem is that the “SoftwareUpdater” program says it needs at least 3 MB more.

18

Thank you for your suggestion. After browsing the site you cite, I find two things:

  1. There is another, potentially simpler, work-around: if I enter “sudo apt update && sudo apt upgrade” in a terminal window, the updating proceeds without a problem. There is no complaint of insufficient space. I have done this now several times without a hitch.

  2. There are many reports of systems becoming unusable after a kernel update. This is potentially a serious problem. Because the procedures for kernel updates for Raspberry Pi are very different from what is done with other Ubuntu installations (and poorly documented), the usual things one does on an Intel-based Ubuntu are not available. There is no grub2 to allow you to choose which kernel to boot (after, say, a problembatic kernel update); and there is no knowledge base I can find that offers maintenence tricks, such as using Synaptic to remove linux-image and linux-header packages that constitute kernels that are no longer needed.

19

I tried the autoremove you suggest – it made no difference in the behavior of SoftwareUpdater.

Your suggestion about listing the installed kernels works great everywhere except on the Raspberry Pi, which is where I encountered the problem.

It doesn’t help that all Raspberry Pi kernels are named “kernel.img” – and I’m unaware of a tool that can be used to tell me what version it is. Invoking “file /boot/kernel.img” just tells me that it is a kernel image for ARM, but offers no information about version number.

20

I thank all the responders for their suggestions.

Here’s where I come out on all of this.

  1. There appears to be a bug in SoftwareUpdater that on some Raspberry Pi systems makes it need (or think it needs) more free space in /boot than a “sudo apt update && sudo apt upgrade” requires to do the actual update itself. Work-arounds, such as using the shell or temporarily moving a kernel-image file out of /boot, are capable of getting the job done.

  2. There is a need for documentation about how to do kernel maintenance on Raspberry Pi systems. What files constitute a kernel release? How can a particular kernel be chosen at boot time? What files are overlaid when the kernel is updated? How can the version number of a “kernel.img” be identified?

If there’s anybody out there on the development team who can share this knowledge, I’d be happy to volunteer my time to write, edit, or proof-read a kernel-maintenance document for the Raspberry Pi. Until then, I’ll have to temper my enthusiasm for installing the security protections of new kernel releases with the knowledge that a failed update may require starting my installation from scratch again.

1 Like