Due to GKI, the kernel UTS release string will not always (if ever)
match the vendor's UTS release string that is used to create the
initramfs file structure -- /lib/modules/<vendor uname>. This causes
module load failures when `-d DIR` is omitted. To fix this, we can
include all of the versions under /lib/modules that match the kernel's
major and minor version instead of directly using the value of uname().
In addition, we can also support modules being loaded directly from
/lib/modules.
Test: verify GKI kernel + initramfs with different UTS strings
Test: verify GKI kernel + initramfs with modules directly in /lib/modules
Fixes: 8320778425 ("toolbox/modprobe: Fallback to /lib/modules/<uname> ")
Bug: 282917063
Bug: 254835242
Merged-In: I5368f5cff139ba3165323a6a91066be38bfa0736
Change-Id: I5368f5cff139ba3165323a6a91066be38bfa0736
Make the module directory optional by reading the kernel release
version. This path is where the kernel installs modules by default.
Similar behaviour can be found in several modprobe implementations.
Bug: 254835242
Change-Id: I61707636705e5b4d9bd8ccf6351e7057eae6bcf5
Remove the function EnableBlocklist() and add a constructor argument to
enable/disable the use of modules.blocklist. In all cases, the
enabling/disabling of the blocklist happens immediately after creating
the Modprobe object. So this simplies libmodprobe.
Additionally, the use of the blocklist by libmodprobe should be enabled
by default unless explicitly disabled during creation of the Modprobe
object. Currently, only modprobe(8) defaults to not using the blocklist
and includes the argument -b BLOCKLIST for enabling it. That
functionality remains.
This refactor allows us to use the blocklist during first stage init.
However, additional logic is needed to not return an error for the
blocked non-aliased modules during first stage init; otherwise, the
error would result in an init crash leading to a device reboot. So fixup
LoadListedModules() to allow blocking modules without returning an
error.
Bug: 182582036
Test: boot test on pixel 5 with a module in modules.blocklist
Change-Id: I394b5aa98fa98821011982cfe693749010c381f7
There is a desire to ensure that modprobe as a service can log to
kmesg to help triage issues, so add support for the -s or --syslog
flag to do so.
SideEffects:
- help goes to stdout instead of stderr.
- verbose flag once, sets DEBUG, twice, sets VERBOSE minimum.
- quiet flag sets WARNING minimum.
Bug: 159424228
Bug: 151950334
Test: use modprobe as a service to load modules, check logs
Change-Id: I884995f364b0fc604861797eb90d7225a372f864
Add a means to specify the modules to load from a file, rather than
on the argument list by adding an optional argument to the --all flag.
This allows modprobe to be designated as a standalone service to load
a long series of modules in the background and be specified
separately. The specified (module.load) file contains a newline
separate list of module names, and supports line comments using '#'
since this file may be maintained by a human or scripting that
requires tagging for regions of the file.
Bug: 159424228
Bug: 151950334
Test: use modprobe as a service to load modules
Change-Id: Id32641c7244e65848fca3a4a82c8d08b2042bf2f
Add support for long options, and fit existing options to upstream
behaviors and extensions. Fix some missing std::endl and
android::base::Join() usage.
Bug: 159424228
Bug: 151950334
Test: manually test long options work
Change-Id: Id792d87d4407628e706aeccecb6e2bce22bcad10
