modules-load shows OK for failed modules?

[hongkongkiwi]

I've seen these issues when some modules can't be loaded (the issues are expected, I was doing a test).

I've got the modprobe plugin and the modules load plugin.

When the modules fail to load, it's strange that the modules load plugin says "OK" shouldn't they say "Fail"?

[ ⋯  ] Cold plugging systemmodprobe: can't load module vpl_vic (vpl_vic.ko): invalid module format
modprobe: can't load module vma_rs (vma_rs.ko): invalid module format
modprobe: can't load module vpl_vic (vpl_vic.ko): invalid module format
modprobe: can't load module vpl_dmac (vpl_dmac.ko): invalid module format
modprobe: can't load module vma_h5cde (vma_h5cde.ko): invalid module format
modprobe: can't load module vma_meae (vma_meae.ko): invalid module format
modprobe: can't load module vma_dce (vma_dce.ko): invalid module format
modprobe: can't load module brcmutil (brcmutil.ko): invalid module format
modprobe: can't load module vma_ifpe (vma_ifpe.ko): invalid module format
modprobe: can't load module vma_ispe (vma_ispe.ko): invalid module format
[ OK ] Kernel module: IMX307.ko
[ OK ] Kernel module: vma_dce.ko
[ OK ] Kernel module: vma_h4cde.ko
[ OK ] Kernel module: vma_h5cde.ko
[ OK ] Kernel module: vma_ifpe.ko
[ OK ] Kernel module: vma_ispe.ko
[ OK ] Kernel module: vma_jdbe.ko
[ OK ] Kernel module: vma_jebe.ko
[ OK ] Kernel module: vma_meae.ko
[ OK ] Kernel module: vma_rs.ko
[ OK ] Kernel module: vpl_dmac.ko
[ OK ] Kernel module: vpl_edmc.ko
[ OK ] Kernel module: vpl_vic.ko
[ OK ] Kernel module: compat.ko
[ OK ] Kernel module: cfg80211.ko

The initctl cond dump shows correct failure status.

1    init                   on      <task/modprobe.cfg80211.ko/failure>
1    init                   on      <task/modprobe.compat.ko/failure>
1    init                   on      <task/modprobe.vpl_edmc.ko/failure>
1    init                   on      <task/modprobe.brcmutil.ko/failure>
1    init                   on      <task/modprobe.brcmfmac.ko/failure>
1    init                   on      <task/modprobe.vpl_vic.ko/failure>
1    init                   on      <task/modprobe.vpl_dmac.ko/failure>
1    init                   on      <task/modprobe.vma_rs.ko/failure>
1    init                   on      <task/modprobe.vma_meae.ko/failure>
1    init                   on      <task/modprobe.vma_jebe.ko/failure>
1    init                   on      <task/modprobe.vma_jdbe.ko/failure>
1    init                   on      <task/modprobe.vma_ispe.ko/failure>
1    init                   on      <task/modprobe.vma_ifpe.ko/failure>
1    init                   on      <task/modprobe.vma_h5cde.ko/failure>
1    init                   on      <task/modprobe.vma_h4cde.ko/failure>
1    init                   on      <task/modprobe.vma_dce.ko/failure>
1    init                   on      <task/modprobe.IMX307.ko/failure>

[troglobit]

It's counter intuitive to say the least, yes.

This plugin was contributed by a 3rd party and I've considered on multiple occasions to at least silence the output at boot. The reason it becomes like this is that the plugin use the task directive with a description. And as you know by now, that calls modprobe in the background. This clumsiness is documented in doc/plugins.md.

Personally I rely on the magic in the modprobe plugin instead, which scans /sys/devices for modaliases and rarely fails to load the modules I need.

[hongkongkiwi]

I see, so if using modprobe how do you ensure services are only running after the module is loaded?

[troglobit]

Another anachronism with the modules-load plugin is that it only runs in runlevels [2345]. So yeah, then you'll run into synchronization issues. I actually changed that default yesterday to [S] (same as the modprobe plugin) and added a set runlevel 2345 directive to the modules-load plugin.

Just pushed the changes (yesterday's and today's).

[troglobit]

The modprobe plugin runs in runlevel S, on HOOK_BASEFS_UP right after the bootmisc plugin. Before any run/task/service have been launched.

With these latest changes, the modules-load plugin's tasks will now run in S as one of the first run/task/services when the Finit state machine starts up, which is right after HOOK_BASEFS_UP.

[troglobit]

I hope these changes help!