No room on /boot for updates

Support & Help Requests Raspberry Pi
#21

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.

1 Like
#22

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.

2 Likes
#23

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]

1 Like
#24

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.

#25

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

#26

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 empty
1 Like
#27

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

#28

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

#29

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

1 Like
#30

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

#31

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. :confused:

#32

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

1 Like
#33

This is EXTREMELY frustrating for new users, especially non-technical ones, or those without another Linux system at their disposal.

This is nearly an out-of-the-box fail. I guess this will teach users to never update their systems. Seems like it would be a very easy to fix in the IMG. It should have been done before now – it’s been months.

-e

1 Like
#34

Forget the default system update program and install Synaptic so you can update everything without having any problems!

1 Like
#35

I like synaptic, it’s what i’ve been using for years.

What i do is, before i install or update anything, i back up my system drive. Then if something get hosed, i can recover the system partition without having to re-do all the customization. FWIW.

1 Like
#36

There is a bug in GUI update, but apt upgrade works no problems!
I have no problem with my default 64MB /boot partition.

1 Like
#37

you can call all this “quite embarassing”, it really sucks… :confused:

#38

like @crankypuss and @vidaldaniel

since the updater seems to want to update kernels and thus fails…

If you still want to to updates with some control of what packages get updated instead of just the blanket
sudo apt update

try installing synaptic package manager
sudo apt install synaptic

within synaptic you can filter just those packages set for update and then update just what you want or everything if you so choose. Since synaptic doesn’t deal with kernel upgrades there won’t be that issue with /boot

unfortunately the mate updater is not as good a program as the one that ships with linux mint which allows easy control, identification and separation of kernel updates from common packages and security updates

1 Like
#39

On a computer with gparted:

  1. Copy the contents of PI_BOOT from the crad to your computer.
  2. Unmount and delete the small partition that holds the PI_BOOT. You will lose about 64 MB. If you try to join this partition later to PI_ROOT, nothing will happen except a sofware corrupted card.
  3. Cretae a new partition of about 1 GB to the right of the free space (it will be on the far right.) Label it PI_BOOT and move/copy the previously backed files from the original P_BOOT partition.
  4. Extend (to the right) the existingPI_ROOT as much as it can.

You can to this step by step or one after the other with gparted.

Enjoy your working installation!

1 Like
#40

This helped for me as I had the same problem !!

1 Like