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

esposem · 2024-11-28T09:02:18Z

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).

I did not implement any test yet.

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 · 2024-12-05T19:25:40Z

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 · 2024-12-06T09:14:47Z

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 · 2024-12-19T11:01:41Z

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 · 2025-01-20T08:56:36Z

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

esposem · 2025-01-27T17:08:37Z

Added doc and the last two commits show a possible fix to the confusing error messages that come up when the first call to MODULES_DIRECTORY fails but the second to MODULES_ALTERNATIVE_DIRECTORY is successful.

esposem · 2025-01-30T07:06:29Z

Finished with first pass of fixes (hopefully waiting reviews).
I modinfo should be completed, meaning it has functionality, docs and test. I fixed (or tried to) all problems described in the PR. Before doing other tests for the other components, I would love to get any feedback on this.

This option allows the user to specify the alternative directory that the kmod tools should look at when MODULE_DIRECTORY is empty. Defaults to /run/modules. Signed-off-by: Emanuele Giuseppe Esposito <[email protected]>

Add a boolean flag at setup time to let the user decide whether kmod should consider the fallback MODULE_ALTERNATIVE_DIRECTORY or not. If this flag is False, MODULE_ALTERNATIVE_DIRECTORY will be ignored. Signed-off-by: Emanuele Giuseppe Esposito <[email protected]>

With the incoming MODULE_ALTERNATIVE_DIRECTORY double logic where the same core function for each kmod tool will be called twice, once on MODULE_DIRECTORY path and another time on MODULE_ALTERNATIVE_DIRECTORY, we need to somehow catch the error and print it only if both calls on these two directories fail. Otherwise we risk to make kmod very confusing for the user because we might show an error first (MODULE_DIRECTORY missing), and then the fallback (MODULE_ALTERNATIVE_DIRECTORY) successfully does its job leaving command is successful. Signed-off-by: Emanuele Giuseppe Esposito <[email protected]>

…issing Currently if no module is found in MODULE_DIRECTORY, kmod will just print "Module %s not found", but now that we are adding two search paths, it is worth specifying which is the path that was not found. Signed-off-by: Emanuele Giuseppe Esposito <[email protected]>

Signed-off-by: Emanuele Giuseppe Esposito <[email protected]>

Move code in do_static_nodes into two helpers: one to get the dirname (MODULE_DIRECTORY/$kernel) and another to do the main logic. This is in preparation to perform the same two steps again for the new MODULE_ALTERNATIVE_DIRECTORY option. Signed-off-by: Emanuele Giuseppe Esposito <[email protected]>