libkmod: tools: Introduce 'module alternative' directory (was: module fallback)

[esposem]

This PR is the improvement of #202 opened by @vittyvk .

Below you find a description of the original PR. The main change here is that if /lib/modules exists, nothing changes in kmod functionality. If, however, for some reasons it misses, /run/modules is used as search path.

The change itself is pretty easy: call twice the same logic for each tool with a different, customizable path (MODULE_DIRECTORY and MODULE_ALTERNATIVE_DIRECTORY).

The only things that is missing is what to do with error prints. As I suggest in the penultimate commit "tools: improve error logs to specify in which dirname is the module missing", it is pretty confusing to see first an error and then a successful output, or even worse no output (because modprobe doesn't print anything if it works).

Something similar also happens in the last commit, where I must decrease the log priority otherwise the second call to the main function in modprobe is not called.

For the above reasons, I did not implement any test yet.

Another consideration is static-nodes: as I understand, it will read a input file from ctx->dirname and then will print informations about the modules. So should it run on both MODULE_DIRECTORY and MODULE_ALTERNATIVE_DIRECTORY?

Original PR description:

Currently, traditional Linux systems using initramfs are forced to keep two copies of the modules which may be needed 
both during early boot and for normal system operation. This seems to be inevitable for the case when initramfs is built 
locally but with the rise of distro shipped UKIs the question whether it would be possible to avoid the redundancy arises.

To make it possible to reuse modules from initramfs without copying them to the root filesystem (which may be 
read-only), the suggested approach is to preserve them on tmpfs, e.g. in /run/modules/uname -r but the challenge is to 
make kmod search there.

[...] this part does not apply anymore [...]

Note, no merging of /run/modules/uname -r and /lib/modules/uname -r is performed. It is expected, that in case 
/lib/modules/uname -r exists, it is a superset and modules from initramfs are no longer needed.

To make a real world example of the usage, Fedora/CentOS/RHEL distros now ship 'kernel-uki-virt' package with a UKI 
which is self sufficient in many cases. The package, however, has to have a dependency on 'kernel-modules-core' so 
basically the same set of modules is available post boot. This is needed when e.g. a filesystem module which was not used 
for root filesystem need to be loaded to mount some other volume (and ESP is the most common example). The desire is 
to be able to break this dependency for 'minimal' cloud/VM images but still support the case when people want to install 
''kernel-modules-core'/'kernel-modules'/'kernel-modules-extra' post boot and enjoy additional modules.

[evelikov]

Can we get a manpage(s) update, on how things are supposed to work? Ideally it will include (either the doc or commit message) some details why the alternative ordering or behaviour isn't warranted.

Once that is solid and we're comfortable things won't backfire/respective workflows are supported/etc, we can beat the code and tests in shape.

[esposem]

Sure, I thought the commit messages and PR description were self explanatory.
The idea is the following:

• If whatever component logic (say kmod_new) for the path MODULE_DIRECTORY (/lib/module) works correctly (no error returned), nothing else is done. The behavior is exactly as it was before this PR.
• If the component logic fails for the path MODULE_DIRECTORY, try MODULE_ALTERNATIVE_DIRECTORY (/run/modules) and see if it works.
  This is done to cover the case where /lib/modules is missing but /run/modules is populated, and fall back into /run/modules ONLY IF /lib/modules is missing. The original /lib/modules has priority over the fallback directory.
  Does it clear some doubts? Happy to explain if something is not clear

[esposem]

Hi @evelikov I am re-reading your notification and I am not sure what you mean with some details why the alternative ordering or behaviour isn't warranted. Can you explain what you mean?

[esposem]

Hi @evelikov can you please answer my question? I will be happy to add manpage if you tell me what you want to see exactly