# OS Update Fails on Raspberry Pi 4 with rpi-update-firmware.bbclass Enabled **URL:** \ **Category:** General Discussions\ **Tags:** yocto, raspberry-pi-4\ **Created:** [November 17, 2024, 3:01pm UTC](https://hub.mender.io/t/os-update-fails-on-raspberry-pi-4-with-rpi-update-firmware-bbclass-enabled/7330 "2024-11-17T15:01:19Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![nomtor0204](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/nomtor0204/32/2355_2.png) [@nomtor0204](https://hub.mender.io/u/nomtor0204)\ **Post date:** [November 17, 2024, 3:01pm UTC](https://hub.mender.io/t/os-update-fails-on-raspberry-pi-4-with-rpi-update-firmware-bbclass-enabled/7330/1 "2024-11-17T15:01:19Z")
Hello, I encountered an issue where OS updates fail on a `raspberrypi4-64` using an image **with `rpi-update-firmware.bbclass` enabled**. I am using the latest commit of the `scarthgap` branch from the `meta-mender-community` repository. The error occurs during the file copy operation in the [`ArtifactInstall_Leave_50.in`](https://github.com/leon-anavi/meta-mender-community/blob/f78692feadf7d76ae7b329ca32fa9f0c4fd9ac97/meta-mender-raspberrypi/recipes-mender/update-firmware-state-script/files/ArtifactInstall_Leave_50.in#L37-L39) script. It seems that the `/uboot` partition runs out of space. #### Logs (standalone update): ```auto record_id=2 severity=info time="2024-Nov-17 14:14:17.972419" name="Global" msg="Update Module output (stdout): ================ STATISTICS ================" record_id=3 severity=info time="2024-Nov-17 14:14:17.972622" name="Global" msg="Update Module output (stdout): Blocks written: 1292" record_id=4 severity=info time="2024-Nov-17 14:14:17.972702" name="Global" msg="Update Module output (stdout): Blocks omitted: 2692" record_id=5 severity=info time="2024-Nov-17 14:14:17.972758" name="Global" msg="Update Module output (stdout): Bytes written: 1354760192" record_id=6 severity=info time="2024-Nov-17 14:14:17.972805" name="Global" msg="Update Module output (stdout): ============================================" record_id=18 severity=info time="2024-Nov-17 14:14:18.854506" name="Global" msg="Running State Script: /var/lib/mender/scripts/ArtifactInstall_Leave_50" record_id=19 severity=info time="2024-Nov-17 14:14:18.864378" name="Global" msg="Collected output (stdout) while running script: /dev/mmcblk0p2 on / type ext4 (rw,relatime)" record_id=20 severity=info time="2024-Nov-17 14:14:45.449390" name="Global" msg="Collected output (stderr) while running script: cp: error writing '/uboot/Image-6.6.22-v8.tmp': No space left on device" record_id=21 severity=error time="2024-Nov-17 14:14:45.481307" name="Global" msg="Failure during Install Leave script execution: NonZero exit code error: Received error code: 1" ``` #### Possible Cause: There was a recent [PR](https://github.com/mendersoftware/meta-mender-community/pull/395) that changed the behavior of `rpi-update-firmware`. Reverting this change allowed the OS update to complete successfully, suggesting that this PR might be the root cause. Additionally, this PR seems to result in `bootfiles`, such as `config.txt`, not being applied to the `/uboot` partition, which may also contribute to the problem. #### Temporary Resolution: As a short-term workaround, I plan to revert the PR mentioned above. #### Request for Guidance: 1. What would be the best permanent solution for this issue? 2. I am unclear why this PR was necessary. If it was introduced to support Raspberry Pi 5, should the processing logic be separated for Pi 4 and Pi 5? Thank you for your time and support. Best regards, ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [November 18, 2024, 4:19pm UTC](https://hub.mender.io/t/os-update-fails-on-raspberry-pi-4-with-rpi-update-firmware-bbclass-enabled/7330/2 "2024-11-18T16:19:16Z")
Hi @nomtor0204, Thanks for the heads up. I’ll try to reproduce the behaviour, so just I understand correctly: - you are starting on which version? Already `scarthgap`, or something else? - can you share the set value of the `MENDER_BOOT_PART_SIZE_MB` variable? Greetz, Josef ---
**Author:** ![nomtor0204](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/nomtor0204/32/2355_2.png) [@nomtor0204](https://hub.mender.io/u/nomtor0204)\ **Post date:** [November 19, 2024, 12:17am UTC](https://hub.mender.io/t/os-update-fails-on-raspberry-pi-4-with-rpi-update-firmware-bbclass-enabled/7330/3 "2024-11-19T00:17:48Z")
Hi @TheYoctoJester, Thank you for your reply. > you are starting on which version? I am using the `scarthgap` branch for Yocto. Below are the commit hashes for the relevant repositories as of 2024/11/12 (latest commits at that time): - meta-mender: `61b6f2298bad965cf6be41ebf11e62e4c314512f` - meta-mender-community: `c33fa9a6934aeca65f61c567ad3585fc6b1a9908` - meta-raspberrypi: `6df7e028a2b7b2d8cab0745dc0ed2eebc3742a17` Note: The latest tag for `meta-mender` on the `scarthgap` branch (`scarthgap-v2024.08`) does not build successfully. To resolve this, I had to build using the latest commit from the branch. The following commit seems necessary to pass the build: [fix: finish fixing persistent machine id support · mendersoftware/meta-mender@89adca7 · GitHub](https://github.com/mendersoftware/meta-mender/commit/89adca75973d941b2010efab7f612b581006c6fe). > MENDER\_BOOT\_PART\_SIZE\_MB The value of `MENDER_BOOT_PART_SIZE_MB` is set to **64MB** , and this is reflected on the device as well. ```auto # df -h Filesystem Size Used Avail Use% Mounted on ...omitted... /dev/mmcblk0p1 64M 49M 15M 77% /uboot ``` I followed the example `local.conf` configuration from the `kirkstone` branch of `meta-mender/meta-mender-raspberrypi`, which recommends 64MB for the boot partition: [meta-mender/meta-mender-raspberrypi README.md (kirkstone)](https://github.com/mendersoftware/meta-mender/blob/kirkstone/meta-mender-raspberrypi/README.md?plain=1#L59). At the time, `kirkstone` was the latest branch. Let me know if you need any further details. Best regards, ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [November 19, 2024, 6:14pm UTC](https://hub.mender.io/t/os-update-fails-on-raspberry-pi-4-with-rpi-update-firmware-bbclass-enabled/7330/4 "2024-11-19T18:14:44Z")
Hi @nomtor0204, Thanks, at least for a first try I could not reproduce the problem. You’re updating from `kirkstone` to `scarthgap` with `rpi-update-firmware` enabled? Greetz, Josef ---
**Author:** ![nomtor0204](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/nomtor0204/32/2355_2.png) [@nomtor0204](https://hub.mender.io/u/nomtor0204)\ **Post date:** [November 20, 2024, 1:37am UTC](https://hub.mender.io/t/os-update-fails-on-raspberry-pi-4-with-rpi-update-firmware-bbclass-enabled/7330/5 "2024-11-20T01:37:53Z")
Hi @TheYoctoJester , > You’re updating from kirkstone to scarthgap with rpi-update-firmware enabled? Yes, I am trying to update from kirkstone to scarthgap with `rpi-update-firmware` enabled. > I could not reproduce the problem. Thank you for checking. It seems the issue depends on the specific configuration. In my case, the size of `/boot/Image-6.6.22-v8` is around 27MB, and since the available space in `/uboot` is only 15MB, the copy operation fails with an error. I believe this issue might occur in other environments as well if the kernel image size is sufficiently large. In the previous version of `rpi-update-firmware`, the transfer of `/boot/Image` was excluded. Is this now required? Based on the following comment, it seems the `Image` file is already part of the rootfs, and there’s no need to copy it to `/uboot`: [raspberrypi: add state script to update boot firmware by mirzak · Pull Request #953 · mendersoftware/meta-mender · GitHub](https://github.com/mendersoftware/meta-mender/pull/953#issuecomment-602847538). Best regards, ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [November 20, 2024, 8:24pm UTC](https://hub.mender.io/t/os-update-fails-on-raspberry-pi-4-with-rpi-update-firmware-bbclass-enabled/7330/6 "2024-11-20T20:24:54Z")
Hi @nomtor0204, Good catch indeed. You’re right, the `Image` file doesn’t need to go to the boot partition. There actually is a long standing PR which might bring exactly the improvements you need ([rpi-update-firmware.bbclass: refactor rpi\_install\_firmware\_to\_rootfs by liuming50 · Pull Request #2114 · mendersoftware/meta-mender · GitHub](https://github.com/mendersoftware/meta-mender/pull/2114)), but it predates the move of `meta-mender-raspberrypi` from `meta-mender` to `meta-mender-community`, and will definitely need some massaging - which I just didn’t find the time for yet ☹ Greetz, Josef ---
**Author:** ![james-onsolution](https://avatars.discourse-cdn.com/v4/letter/j/7bcc69/32.png) [@james-onsolution](https://hub.mender.io/u/james-onsolution)\ **Post date:** [December 29, 2025, 5:48am UTC](https://hub.mender.io/t/os-update-fails-on-raspberry-pi-4-with-rpi-update-firmware-bbclass-enabled/7330/7 "2025-12-29T05:48:37Z")
Hi @TheYoctoJester , I’m seeing the same error as @nomtor0204 was seeing when moving to Scarthgap. I noticed that this PR has been closed as it was stale. Just wondering if this is still the recommended solution to this issue? [rpi-update-firmware.bbclass: refactor rpi\_install\_firmware\_to\_rootfs by TheYoctoJester · Pull Request #441 · mendersoftware/meta-mender-community · GitHub](https://github.com/mendersoftware/meta-mender-community/pull/441) Thanks! ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [January 9, 2026, 1:45pm UTC](https://hub.mender.io/t/os-update-fails-on-raspberry-pi-4-with-rpi-update-firmware-bbclass-enabled/7330/8 "2026-01-09T13:45:28Z")
Hi @james-onsolution, Not sure where it got stuck, to be honest. If this is helpful to you and you probably have it on a local branch where you test it, would you mind re-submitting? Greetz, Josef