Hello,
I hope this is the rigth place for my question.
I have already integrated mender dual rootfs update mechanism on a custom board, but now I need additional files in the payload. Since this is not possible with a rootfs-image, I thought I’d use the rootfs-image-v2 update module.
I should note that I have an UBIFS filesystem where it is not possible to simply cat the payload into the inactive partition, but rather have to use ubiupdatevol tool. The problem I have now is that this tool only accepts a pipe when specifying the payload size. Unfortunately I couldn’t find a way to get the size of the first file in the payload.
Alternatively, I skipped the Download state so that the payload gets extracted to the filesystem. This works, but takes about 2.5 times of the built-in rootfs update. I looked into the mender client code to see how they do it, and if I understood correctly, it also passes to the ubiupdatevol utility the size of the file it got from reading the 0000/data.tar.gz archive. So the information is there.
Is there any possibility to retrieve this information in an update module too?
Not currently, but this would be a useful addition. As part of the client rewrite in C++, the rootfs-image updater will be separated from the main daemon and turned into an update module. So this is something we in Northern.tech will also likely encounter. I think I can say pretty confidently that this will be solved in the next year or so.
The workaround I would suggest to you in the meantime is to use the entire volume size as the parameter to ubiupdatevol, and if you find that the data returned in the Download stage is smaller than that, you just fill the remainder with zeros to match its expectations. This can be somewhat wasteful, but in most cases the update size is likely quite close to the volume size, perhaps even exactly.
So I’ll be looking forward to when the C++ rewrite is complete.
Also thank you for your workaround suggestion, though in my case the ubi volume is significantly bigger than the file size.
For now I found a different workaround approbriate: I add a simple text file to the start of the artifact payload which depicts the size of the ubifs image. It will be created automatically by my custom artifact-generation script. Perhaps not the most elegant solution, but now I am satisfied with the performance, which is only slighty slower than the native rootfs-image
