Slightly rework things so that we can provide a kernel release/version
tag to mkinitfs and have it only operate on that, suffixing all the
relevant files and passing the info on to boot-deploy.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
This is the path used on usrmerge distros, try it first as /lib/modules
will implicitly follow the /lib symlink.
Signed-off-by: Caleb Connolly <caleb@connolly.tech>
There are several valid extensions that kernel modules can have, and the
list I had here was not complete... this meant that mkinitfs would fail
to include modules with extensions like ".ko.gz" when searching
directories.
This makes the check for a "valid" module file name a lot simpler,
allowing any file with ".ko" in the file name. While it's possible for a
non-module file to have ".ko" somewhere in the file name, it seems
unlikely if it's in the kernel modules directory... and this is an OK
compromise for now.
I think this was still causing some confusion, since it *might* look
like a failure when in reality it's not. I think it's important that
mkinitfs prints when it is adding something, and doesn't print when it
is *not* adding something, so that it should be clear if something
expected is missing and when something unexpected is included... without
having to sort out which is which every time the output is read.
Another one found by fieldalignment:
modules.go:18:14: struct with 32 pointer bytes could be 24
Probably not going to matter much... but let's just get rid of the
warning.
When this is printed, it's about to search the given path for stuff to
slurp up, but it hasn't actually included anything yet. Using
"Including" here was kinda confusing, so this changes it to use
"Searching for." Hopefully that's better!
By doing so, it adds more useful context to this:
- Including kernel modules
-- Unable to find dir, skipping...
- Including kernel modules
-- Unable to find dir, skipping...
This is kinda janky, passing both a list of modules and a directory path
is just because we support modules in deviceinfo and in directory file
lists... Maybe one day we can move away from having modules in the
deviceinfo...
