Problem Description
After the last software update my boot partition, vfat - mounted as /boot/firmware, size 270 MB, is full.
That last update included linux-image-6.1.0-22-arm64. I’ve had problems in the past before, where I had to do a clean re-install, say every 6 months, because of not being able to run any further software updates, or crashes of my FreedomBox. I fear of running into that again.
Is there anything I can/should do now to prevent this from happening?
My setup is:
Raspberry Pi 3 Model B Plus Rev 1.3, installed from downloaded image
running from sd card, 32 Gb,
second partition, btrfs, mounted as / 8 GB/ 32 GB in use
FreedomBox version 24.13, system is up to date
installed software Radical
Tried doing that via the terminal, which resulted in
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
The following packages will be REMOVED:
linux-image-6.1.0-20-arm64
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
3 not fully installed or removed.
After this operation, 356 MB disk space will be freed.
Do you want to continue? [Y/n]
quota not working (qgroup not set)
(Reading database … 67142 files and directories currently installed.)
Removing linux-image-6.1.0-20-arm64 (6.1.85-1) …
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-6.1.0-20-arm64
/etc/kernel/postrm.d/z50-raspi-firmware:
cp: error writing ‘/boot/firmware/initrd.img-6.1.0-22-arm64’: No space left on device
run-parts: /etc/kernel/postrm.d/z50-raspi-firmware exited with return code 1
dpkg: error processing package linux-image-6.1.0-20-arm64 (–remove):
installed linux-image-6.1.0-20-arm64 package post-removal script subprocess returned error exit status 1
dpkg: too many errors, stopping
Errors were encountered while processing:
linux-image-6.1.0-20-arm64
Processing was halted because there were too many errors.
quota not working (qgroup not set)
E: Sub-process /usr/bin/dpkg returned an error code (1)
I was expecting /boot to be a partition and to be full, like on the Pioneer, but apparently on your device it is not so, the partition that is full is /boot/firmware.
Apparently, the kernel (vmlinux) and init ramdisk (initrd) files are duplicated in /boot and /boot/firmware, the “sudo apt autoremove” command removed the ones for 6.1.0-20-arm64 from /boot but not from /boot/firmware.
What I would try (but this could mess up things):
delete /boot/firmware/initrd.img-6.1.0-20-arm64 and /boot/firmware/vmlinuz-6.1.0-20-arm64 (sudo rm /boot/firmware/initrd.img-6.1.0-20-arm64 /boot/firmware/vmlinuz-6.1.0-20-arm64)
run sudo apt autoremove again
Because this could mess up things, before doing that, I would backup /boot/firmware by putting the micro SD card into another GNU/Linux computer and running dd if=/dev/sdX1 of=boot-firmware-partition-backup.img (X needs to be replaced with the correct letter, you can find it by running lsblk --fs and see the partition that is 256 MB and ext2).
If the computer is running GNU/Linux with systemd (like Debian, Ubuntu or similar), before inserting the micro SD card in it, run sudo systemctl stop udisks2.service so that the computer does not try to mount it automatically when inserted.
That said, I don’t know why you are running into that issue. Obviously, your /boot/firmware partition can contain at most 3 (kernel + initram disk), not sure why you have 4.
dpkg -l raspi-firmware
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-===============-============-================================================
ii raspi-firmware 1.20220830+ds-1 all Raspberry Pi family GPU firmware and bootloaders
@Avron : as much as I appreciate your solution, and I do, I’m afraid it is just a temporary solution. A few kernel updates down the road, and I’m back where I started.
This was fixed in raspi-firmware 1.20230405+ds-1, so it has been fixed in unstable and testing. However, Debian stable has raspi-firmware 1.20220830+ds-1, and I don’t see any bugfix updates for it.
So I would recommend that we request to the raspi-firmware maintainers to see if the fix can be applied to raspi-firmware in Debian stable. I see they have a mailing list here: Pkg-raspi-maintainers Info Page
Now that we know that it is a bug in raspi-firmware, and that the fix is not yet available in Debian stable, is there a fail save temporary solution that an inexperienced user like me could apply right now? New updates of other packages have arrived but I can’t install these now, as the process is blocked by the unfinished update of the kernel.