Missing mtd-utils-ubifs dependency

[Urist-McGit]

When installing a tarred filesystem on an ubifs slot, mkfs.ubifs is used to format the slot. If the binary is not available you get the following error message:
LastError: Installation error: Failed updating slot rootfs.1: failed to start mkfs.ubifs: Failed to execute child process ?mkfs.ubifs? (No such file or directory)
A short search brought up that mkfs.ubifs is available in the mtd-utils-ubifs recipe from the meta layer. Manually adding the recipe for my image solved the issue.

[ejoerns]

@Urist-McGit the problem is that we cannot easily make assumptions on what tools your target requires to perform slot writing with RAUC. This will heavily depend on the storage type and file system you use. It is also not an option to simply add all potentially possible dependencies as this would mean quite a large overhead of useless packages on most systems.

Thus currently it is up to the integrator to add the non-generic target dependencies required.

Two potential options to solve this would either be to parse the system.conf and derive this information or to add something like explicit PACKAGECONFIG pseudo options to the bundle class to manually select the use case and thus the required target dependencies.

Personally, I do not see a really great benefit from both at the moment. Other opinions and better approaches are always welcome ;)

[Urist-McGit]

Thanks for the quick reply!

It is also not an option to simply add all potentially possible dependencies as this would mean quite a large overhead of useless packages on most systems.

You make a good point with the ballooning install size of RAUC if we always considered all possible install options. But I am not quite happy with the current state, even if such cases as mine were documented somewhere.

Two potential options to solve this would either be to parse the system.conf and derive this information or to add something like explicit PACKAGECONFIG pseudo options to the bundle class to manually select the use case and thus the required target dependencies.

An automated approach by parsing the target slot type and image file name in bundle.bbclass seems like a possible approach, no? Since RAUC does the same matching of image and slot type in update_handler.c.

[ejoerns]

@Urist-McGit Yes, it could be one part of the game but you'd also have some cases where you cannot derive required tools from the target only (like knowing whether or not tar or casync support is required), but maybe that is maybe a tradeoff between usability and a minimal overhead for simply installing all possibly system.conf-relevant tools.

[Urist-McGit]

Good point, that would mean any automated approach on its own is futile, though. We would need the user to specify his use case (slot types, image types, tar/casync support) and build dependencies from there. If these options were not specified we could still build these with the parsing approach and cover a minimal implicit use case. I think this might be a good solution for the problem, what do you think @ejoerns ?

[ejoerns]

@Urist-McGit Yes, sounds like a plan if we ensure that the final list is overridable by custom selections.

Config parsing and handling in python should not require much effort, maybe something like this would already work:

import configparser

cf = configparser.ConfigParser()
cf.read('system.conf')

types = set()

dependency_map = {
        'vfat': 'dosfstools',
        'ext4': 'e2fsprogs',
        'ubifs': 'mtd-utils-ubifs',
        }

for section in cf.sections():
    if not section.startswith("slot."):
        continue
    if not 'type' in cf[section]:
        print("Error, no 'type' in section")
    types.add(cf[section]['type'])

for t in types:
    print(dependency_map[t])

[ejoerns]

Hm.. thinking about that again I currently don't have a clue how to access system.conf in the parsing process already.
And after parsing (e.g. after do_fetch() is completed) it should be too late to add build/runtime dependencies.

Another option would be to issue warnings when building a dependency list based on the system.conf in WORKDIR and comparing it to the actual RDEPENDS list in your package. But that might produce too many false-positive warnings.

[Urist-McGit]

I have also played around a little and I too have not found a way to do it. There is no (clean) way to get system.conf at recipe parse time, which is needed for Yocto to actually register the dependencies. That means we need an explicit statement in the recipe itself.

Giving warnings seems like the right way to do it. There should be a way to disable them and tell RAUC that you know what you are doing, and some new options to tell it what the use case is.

I will probably come around to create some patches in the coming weeks, then we can see how everything looks and if we actually like it.

[ejoerns]

@Urist-McGit Did you have any good clue for this? Otherwise, I would like to close this first of all.

[Urist-McGit]

I did not put any more serious effort into it, unfortunately. Feel free to close this :)