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

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,