NotEnoughSpace exception for update although we have anough space

[NLueg]

Hello!

We need to increase the size of the yocto partitions. After we did this we are no longer able to update the image using UpdateHub. Without the storage increase, we're neither but probably because the partition is really too low to download our custom packages and still be able to download and extract the uhupkg. We use the current kirkstone version for Yocto.

Do you have an idea what could be the issue and how we're able to increase the size of devtmpfs or how to change the partition that UpdateHub uses to install the update?

Thank you so much for any help. Feel free to ask if you need anything else related to our configuration to analyze the issue.

More Context

We just made it to run UpdateHub with Yocto on our Raspberry PIs and everything looked well in the first place. We have some custom code in our image that downloads + starts some Docker containers which of course consumes some storage. Because of that, we had to increase the storage with the use of some Yocto variables. After some trial + error, we use these parameters:

# Set the rootfs size to 10GiB * 1.3 = 13GiB.
# IMAGE_OVERHEAD_FACTOR is set to 1.3 (which is the (buggy), non-overridable default value), so that in case the value gets changed, we still end up with the same image size.
# Since we need to multiply by 2 (~26GiB total) and add some MiB for Bootloader and padding, we still have ~1.6GiB left on our 32GB (29.7GiB) SD-Cards
IMAGE_ROOTFS_SIZE:forcevariable = "10485760"
IMAGE_ROOTFS_MAXSIZE:forcevariable = "10485760"
IMAGE_ROOTFS_EXTRA_SPACE:forcevariable = "0"
IMAGE_OVERHEAD_FACTOR:forcevariable = "1.3"

This is working fine so far, although this leads to a larger image because the empty bits & bytes are included in the image. The download size for the gz file is still below 300MB.

Issue on update

The image is working fine and we can see that the storage is increased. But when we try to update the device it seems like updatehub only uses devtmpfs to download and extract the image which of course is too small:

[je-s]

Hello,

additional to what @NLueg wrote: The exception gets raised in this function (the function is called multiple times during the update process, see the references): https://github.com/UpdateHub/updatehub/blob/91bea148863ddae957068f5da93f8b1add57ea03/updatehub/src/utils/fs.rs#L26

We suppose the following:

1. In order to apply the update, UpdateHub should check the size of the second partition and whether the partition is big enough for the update to come.
2. Since the last log before that error is INFO 'raw' handle checking requirements, the error is probably happening here: https://github.com/UpdateHub/updatehub/blob/91bea148863ddae957068f5da93f8b1add57ea03/updatehub/src/object/installer/raw.rs#L30
3. Since the available disk space is exactly the size of devtmpfs, the check probably doesn't validate the partition size that is targeted for the update (e.g. /dev/mmcblk0p2 or /dev/mmcblk0p3 on a SD-Card), but the size of devtmpfs itself, which then would end up in this error.

Maybe that helps. We're thankful for any hint. :)

[otavio]

Please provide the following information:

• The /etc/updatehub.conf from the running system
• Are you using the cloud to send the update package or the local file to install the package?
• The uhupkg.config

To clarify a few concepts. We need to be mindful of storage space in two locations. The destination will be checked based on the target of the artifact being installed. Additionally, we must monitor the temporary directory where the objects will be downloaded. This is where the download directory comes into play.

[otavio]

I'm wondering if you are using the tarball backend or the raw installation method for the RootFS.

Please provide the list of layers that you are using.

[otavio]

@NLueg Have you made any progress on this issue? I'm wondering if you forgot the issue or do you still need some assistance?