Image type detection to include ".verity" rootfs extension

[Gerry546]

Is your feature request related to a problem? Please describe.
Currently I'm working on integrating dm-verity support together with RAUC in a system.
Using the bbclass provided in meta-security (https://gitlab.com/akuster/meta-security/-/blob/master-next/classes/dm-verity-img.bbclass) to add verity support to the image this class will ensure that the rootfs images are in the DEPLOYDIR and all are appended with .verity. These can then be included in .wic and bundles via raw copies as specified in the RAUC documentation.
As mentioned in the RAUC docs my system.conf is adjusted to do raw copies only. This also has as a consequence (AFAIK) that the rootfs bundled into the image needs to have the .img extension for the RAUC installer to properly handle the raw type.

Describe the solution you'd like
Ensure the RAUC understands any rootfs slot with the extension .verity (such as .ext4.verity, .btrfs.verity) when handling a raw copy.

Describe alternatives you've considered
Fow now I have patched rauc v1.9 to enable these.
Alternatively I was considering to simply rename the files during a build such that RAUC will correctly pick them up.

[ejoerns]

@Gerry546 It's always a compromise between what we say are supported standard image types that we should have in the list and which are just some special cases following a custom naming convention. In the past we have adapted some of the built-in supported file name extensions to match at least what oe-core provides you. I am not sure if we should also cover meta-security or if this in the end makes the mapping scheme too complex and confusing.

So for now, what should work and should be supported by meta-rauc, in case you use this for integration is to use

RAUC_SLOT_verity[type] = file

This will let meta-rauc add a generic .img to the original file name and this in turn will then be correctly recognized and handled by the img_to_raw_handler in RAUC. Would that be sufficient for your use case?

[Gerry546]

I understand your comment and it is indeed always a compromise.
I will try with the type = file and the .img extension to see if this works.

Thank you for the comment so far

[jluebbe]

@Gerry546 Is this issue solved for you?

[Gerry546]

@jluebbe The issue can be considered resolved. I understand the necessary tradeoff between 'commonly' used data and extension types (like mentioned in #1201 ) and the need to keep this system to a sort of standarized set of items.
I would still argue for the inclusion of more data types since the proposed .img types is not one of the native types supported out of the box as dictated here I believe: https://docs.yoctoproject.org/ref-manual/variables.html?highlight=image_fstypes#term-IMAGE_TYPES.

[Louson]

Hello. Sorry to resurrect the post (but the issue wasn't closed). Could we have fallbacks for every destination in update_handlers.c, in the updatepairs list ?

For example:

        {"*", "ext4", img_to_fs_handler},
        {"*", "raw", img_to_raw_handler},
        {"*", "ubivol", img_to_ubivol_handler},

So we don't include anything about verity

[Louson]

@Gerry546 It's always a compromise between what we say are supported standard image types that we should have in the list and which are just some special cases following a custom naming convention. In the past we have adapted some of the built-in supported file name extensions to match at least what oe-core provides you. I am not sure if we should also cover meta-security or if this in the end makes the mapping scheme too complex and confusing.

So for now, what should work and should be supported by meta-rauc, in case you use this for integration is to use

RAUC_SLOT_verity[type] = file

This will let meta-rauc add a generic .img to the original file name and this in turn will then be correctly recognized and handled by the img_to_raw_handler in RAUC. Would that be sufficient for your use case?

Unfortunately, that does not solve the issue if the destination is a ubi volume