OS Update Fails on Raspberry Pi 4 with rpi-update-firmware.bbclass Enabled

General Discussions
,
1

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 script. It seems that the /uboot partition runs out of space.

Logs (standalone update):

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 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,

2

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

3

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.

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.

# 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).
At the time, kirkstone was the latest branch.

Let me know if you need any further details.

Best regards,

4

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

5

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.

Best regards,

6

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), 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 :frowning:

Greetz,
Josef