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"-"`@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.
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!
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.
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.
Thank you for your suggestion. After browsing the site you cite, I find two things:
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.
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.
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.
I thank all the responders for their suggestions.
Here’s where I come out on all of this.
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.
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.
I am intrigued what you actually ran (the EXACT command) [quote=“pdtyma, post:1, topic:11336”]
Software Updater
[/quote]
The PI /boot structure is quite different from normal Linux, and AFAIK it is NOT POSSIBLE to update the firmware using the normal dist-upgrade, or at least if you try it will destroy the image. (I last tried this on 15.04.)
The “recommended” method of updating firmware is rpi-update, although this is not without its problems.
On the other hand a normal update and upgrade should not touch the boot sector. (Unless there has been some change since 16.04.
To answer you question kernel.img is not needed (this is for ARM6). You can remove any .dtb for models you don’t have e.g bcm2708-rpi-b-plus.dtb, the B+ wouldn’t run Ubuntu anyway. These are generally small files, so make little impact.
You could remove start_x.elf if you don’t use the camera module.
Incidentally all the recommendations and comments about running clean are futile, as none of the files are on /boot.
Two issues are being confused here: one is software updates and the other is kernel updates.
Software updating is achieved by ‘sudo apt update && sudo apt upgrade’ for software installed on /ROOT. This does not update the kernel or the /BOOT partition files.
Kernels (modules and firmware) are updated with ‘sudo rpi-update’. After a new kernel is installed and your PI has been rebooted, old kernels and their modules can be removed.
‘uname -a’ will tell you the name of the running kernel, something like ‘Linux RPI-3 4.4.47-v7+ #961 SMP Sun Feb 5 20:17:00 GMT 2017 armv7l armv7l armv7l GNU/Linux’
You can safely go to /lib/modules and remove earlier versions (4.4.46*, for example). This will require root permission.
None of this will prevent Software Updater from complaining, but your system will have up-to-date software and kernel.
If you have a spare SD card, you can use Ubuntu’s disk utility installed on a regular laptop to image the card as backup.
One commenter asks why software updating and kernel management have been confused in this topic. It appears that they are not so much confused as needlessly coupled on the Raspberry Pi because the SoftwareUpdater application complains about insufficient space on /boot (where the kernel is) as a reason why it can’t perform its updates (which don’t seem to need it).
This led to questions about whether and how to manage the contents of /boot so that SoftwareUpdater no longer fails to run.
There is no doubt that the /boot structure on a Raspberry Pi is different from what one commenter refers to as “normal” Linux. The idiosyncratic nature of Pi kernels is what leads to the difficulty in their maintenance: there is no support for kernel maintenance through package management, and there is no readily available knowledge base to consult as to what exactly constitutes a Pi kernel release in order to direct manual maintenenance. Furthermore, there appears to be no ability to choose at boot time which kernel version to run, which would allow bypassing a new but troubled kernel in favor of the last one that ran OK.
All of this contributes to making Pi kernel updating needlessly problematic. Simply moving forward by using only rpi-update to install the “latest and greatest” kernel is not a realistic option because recovery from a kernel update that fails to work properly is very difficult to do on a Pi. You can’t boot around a failing kernel, and no one seems to know how to restore the previous version. At a minimum it appears that one has to remove the SD card from the Pi, mount it on another Linux system, and do something, whatever that might be. There is also the matter of ever-accumulating detritus from defunct kernels.
The Pi updates produce a directory structure /boot.bak. Is rollback as “simple” as replacing the contents of /boot with what is stored in /boot.bak (which could require the use of another Linux system, if the latest Pi kernel does not run properly)? I can’t find any documentation that says so.
Parts of the kernels are apparently stored in directories under /lib/modules. So one manual maintenance task might be to remove directories with version numbers lower than the kernel in use. Maybe you should keep the version that corresponds with what is in /boot.bak. But there doesn’t seem to be a tool (or documentation pointing to the use of tools) to allow one to determine exactly what is the version number of the kernel.img file in /boot.bak. Running “file /boot.bak/kernel.img” provides no numerical release information.
One commenter went so far as to suggest that /boot/kernel.img could be safely removed. Maybe it can, but then why does /boot/config.txt describe /boot/kernel.img as the kernel that is booted by default?
Let’s consult the man pages or maintenance wikis. [sound of crickets]
I’ve just got my Raspberry Pi 3, but I know already that I’ll be trying to achieve a similar setup to openSUSE: uboot + grub2. When my laptop dies (very very imminent), the pi will be the only computer in the house and I won’t have the option of taking the sd card out and sticking it in another computer to fix.
I’ll also be exploring using a standard kernel. Don’t like the idea of the raspberry pi foundation one.
[quote]there is no support for kernel maintenance through package management[/quote] may be true for the Ubuntu MATE distribution, but Arch and the recent Raspbian releases do kernel updates as part of “upgrade”. Former Raspbian releases required a “dist-upgrade”.
The current Raspbian cache contains:-
raspberrypi-bootloader_1.20161215-1_armhf.deb
raspberrypi-kernel_1.20161215-1_armhf.deb
[quote]there is no readily available knowledge base to consult as to what exactly constitutes a Pi kernel release in order to direct manual maintenenance[/quote] is unfortunately true. While https://github.com/raspberrypi/firmware contains kernels the process by which the Foundation decides a stable release is a mystery. Generally the kernel in the Foundation releases is quite stable.
[quote]there appears to be no ability to choose at boot time which kernel version to run[/quote] is true, although it is possible to swap kernels using the “kernel=” parameter in config.txt.
[quote]All of this contributes to making Pi kernel updating needlessly problematic. Simply moving forward by using only rpi-update to install the “latest and greatest” kernel is not a realistic option because recovery from a kernel update that fails to work properly is very difficult to do on a Pi. You can’t boot around a failing kernel, and no one seems to know how to restore the previous version. At a minimum it appears that one has to remove the SD card from the Pi, mount it on another Linux system, and do something, whatever that might be. There is also the matter of ever-accumulating detritus from defunct kernels.
The Pi updates produce a directory structure /boot.bak. Is rollback as “simple” as replacing the contents of /boot with what is stored in /boot.bak (which could require the use of another Linux system, if the latest Pi kernel does not run properly)? I can’t find any documentation that says so.[/quote]
The above seems to be an artefact of rpi-update, which is not intended for ordinary users, although for Ubuntu MATE this seems to be the only option.
Indeed the Foundation engineers warn about this “In normal circumstances there is NEVER a need to run rpi-update as it always gets you to the leading edge firmware and kernel and because that may be a testing version it could leave your RPi unbootable”. https://www.raspberrypi.org/forums/viewtopic.php?p=916911#p916911
Arch and the recent Raspbian releases do not leave “ever-accumulating detritus” (although the Former Raspbian releases did leave older modules).
I don’t know where this came from, I do not see it in my /boot/config.txt. kernel.img is the ARM6 kernel, so by definition unused by Ubuntu. Mind you , there seems to be no reason to remove it.
I just updated my installation to
Operating System: Ubuntu 16.04.2 LTS
Kernel: Linux 4.4.38-v7+
The update includes raspberrypi-bootloader (1.20161215-1~xenial1.0)
Ubuntu MATE seems to have joined Arch and Raspbian in updating kernel (to the latest Foundation supported version).
Ubuntu MATE still seems to leave old ‘/lib/modules’, although it appeared to try (possibly an artefact of previous rpi-update use).
dpkg: warning: unable to delete old directory '/lib/modules': Directory not emptyWhat about using “sudo SKIP_BACKUP=1 rpi-update” to avoid making backup of /boot and /lib/modules files or “sudo PRUNE_MODULES=1 rpi-update” to delete unused module directories when doing an update?
See the “rpi-update” documentation for further info on the options tu update the kernel firmware on the /boot directory.
Now that Ubuntu MATE includes firmware updates, like Raspbian, there is no need to use rpi-update.
I am glad that the rpi-update documentation now warns “Even on Raspbian you should only use this with a good reason. This gets you the latest bleeding edge kernel/firmware.” Not that anyone will heed the warning (or even read the message).
REALLY pleased to finally have Ubuntu on a Pi (RPi 3, 16GB SanDisk class 10 microSD card), and it seems very responsive - hat’s off to the folks who’ve put in the hard work !
I tried this before and had a similar problem to dusty, the 64MB boot partition.
It is force of habit to do and update/upgrade with a new installation, but this fell over immediately due to a lack of space on /boot
To work around this, what I ended up doing was making TWO cards with the 16.04 image on them, then:
1 - boot off the first card, let it do it’s resize and get to a working screen
2 - shutdown, remove first card, put second card in and boot from that
3 - let it resize and get to a working screen, install gparted
4 - put the first card in a USB card reader and attach the Pi’s USB port
5 - fire up gparted, delete the boot partition on the card in the reader, resize the other partition (PI_ROOT) and move it right by 1GB (we need the space at the start of the card)
6 - let it complete the move - takes a little while
7 - create new FAT32 partition at the BEGINNING of the card, label it PI_BOOT
8 - copy the contents of /boot on the “running” card into the newly created partition
9 - shutdown, and swap the cards over
10 - boot up and check that all is well, install gparted again
11 - repeat steps 5, 6, 7 and 8
12 - finally, shutdown and swap the cards again to check the new card is working
It didn’t take THAT long (well, OK, I admit, I got it wrong on my first run through and deleted the WRONG /boot partition (the one I was using !)) and I could do all of this on a single Raspberry Pi once I’d thought about it.
I also note I didn’t NEED to make /boot 1GB in size, I considered 512MB initially, but in the end it’s going to take me a while to use all the space, so chose 1GB as a round(ish) figure.
Cheers
Simon
I agree Simon, I went down a similar path, copying the contents PI_BOOT to my hard drive, unmounting both PI_BOOT and PI_ROOT then using GPartEd to delete the PI_BOOT from the SD Card, decreased the PI_ROOT by 200Mb in my case (and because of my 12Gb website on a 32Gb card it took 9 hours to do it, so don’t panic, it should work). Using GPartEd I formatted the free 200Mb to FAT16, labeled it PI_BOOT and returned the contents of the PI_BOOT to it from the hard drive. Crossed my fingers, returned it to the RPI3 and it booted OK. I was then able to run whatever upgrades that were indicated without any errors after that. I had problems with the Pimoroni PHAT I had on it, but following the website’s installation instructions it was cured with one run. However I will be buying a second 32Gb SD card to image the whole thing next time I experiment. Waiting for overnight 9 hours was excruciating.
Cheers, Rob
I tried that but it won’t let you increase the size of the boot partition. You can only adjust the size of the root partition. 
I may have left a step out, but I reduced the PI_ROOT, and the space released appears as a new “empty” space, the old deleted PI_BOOT space is still there, but the 200Mb I freed is then designated as the PI_BOOT. So the old PI_BOOT space remains in place but un-named and unused. The PI_BOOT files are then copied and pasted back into the new PI_BOOT 200Mb. Apparently the order of the partitions is not critical. On a 32Gb SD card this loss of space is not really a problem.
Cheers, Rob