Support SquashFS compressed bundles on poky

[om26er]

Adds support for LZO and ZSTD based rootfs bundles. This add support for both casync bundles and the "normal".

This PR also fixes a bug *.squashfs.caibx case as it doesn't work with ubivol

[om26er]

For info, those rootfs image names come from http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/image_types.bbclass#n106

[ejoerns]

@om26er Thanks for your PR

Yes, this is not really necessary to support compressed bundles, it would only be necessary to support compressed bundles generated by the Yocto image.bbclass naming convention (as you just noted while I was writing 😏 ). However, it might make sense to support these as Yocto is kind of a 'standard'. The commit message should reflect this probably.
Maybe it is also more generic to make a glob match for *.squashfs* instead of listing each individually?

About your note on ubivol not being supported: Please have a look at: 2b6917a Did you check that? It is probably not that obvious in the code as it should be..

[codecov]

Codecov Report

Merging #747 (a571725) into master (45a26c8) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #747   +/-   ##
=======================================
  Coverage   72.57%   72.57%           
=======================================
  Files          28       28           
  Lines        8937     8941    +4     
=======================================
+ Hits         6486     6489    +3     
- Misses       2451     2452    +1     

Impacted Files	Coverage Δ
src/update_handler.c	55.48% <ø> (ø)
src/install.c	83.00% <0.00%> (-0.05%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ed1fd63...a571725. Read the comment docs.

[jluebbe]

As there is no relevant difference between these images from rauc's perspective, it seems easier to solve this on the Yocto side instead of adding more and more extensions to rauc.

[om26er]

@ejoerns I have now updated the PR to use globbing, I think that makes sense as there are multiple support compression formats. Also updated the commit message

[ejoerns]

As there is no relevant difference between these images from rauc's perspective, it seems easier to solve this on the Yocto side instead of adding more and more extensions to rauc.

From my point of view (even if I don't have a super-strong opinion on this), it would be an acceptable trade-off to add a simple glob and be able to support the default image names generated by yocto. The alternative would be to have a workaround for each Yocto BSP generating compressed squashfs names. Or what do you mean by solving this on Yocto side?

However, if that should be acceptable, the commit message would still need to be extended.

[om26er]

However, if that should be acceptable, the commit message would still need to be extended.

Can you suggest a "good" commit message, please ;-)

[ejoerns]

something like

src/update_handler: support oe-core's default SquashFS image suffixes

The Yocto/OE 'image_types' class generates SquashFS images with different file name suffixes, depending on the compression selected (e.g. .squashfs-xz, .squashfs-lzo).
With our current image pattern, this would require an extra renaming step (to .squashfs) to allow RAUC to properly recognize the image as a SquashFS.

With the minimal invasive change of extending the glob to also match the squashfs-<compression> naming scheme, one could use the images directly.

As Yocto/OE is probably one of the most common build ecosystems RAUC is currently used with, this appears to be an acceptable compromise.

@jluebbe you may want to choose if you would follow this argumentation or not ;)

[jluebbe]

I've changed the commit message based on what @ejoerns suggested.

Instead of the *.squashfs* pattern I've added explicit matches for the currently existing image IMAGE_CMDs in Yocto/OE:
https://github.com/rauc/rauc/compare/44df5cda933b3cc947d4d3b88a1258c343e48b64..302574a64276ed383a842125be963e73f5f5ebbd

[jluebbe]

I've re-added the -zst extension which i lost during my previous rework.

[ejoerns]

Looks fine for me.

However, for similar future cases, having a mapping in meta-rauc might still be a more future-proof approach.