modprobe task condition changed?

[hongkongkiwi]

I've noticed a backwards breaking bug in the latest version, or atleast for the featureI was using.

Previously I was using this task to know if the module is loaded: `<task/modprobe.brcmutil.ko/success>

But it appears to have been changed to have a line number (?) <task/modprobe.brcmutil.ko:15/success>

How can we know this line number? Will it change later? As I have multiple files in /etc/modules-load.d/*.conf I am not sure the line number will remain the same if I add more files.

Is it possible to revert back to the old format without the line number and just using the module name?

[troglobit]

Hum, I believe this was actually a fix to issue #252 that you reported. That name:foo and :ID was not respected for task stanzas. I'll double check later to tonight, but if you could share your complete .conf line here that would be most helpful.

[troglobit]

The only way for me to reproduce your report is to explicitly set :15, like so:

task name:modprobe.esp4.ko :15 modprobe esp4.ko -- Load kernel ESP

[hongkongkiwi]

At the moment, I don't have any specific tasks for this, it's done via the modules-load plugin.

(I've renamed the modules for privacy)

/etc/modules-load.d# cat 01-mymodules.conf
mymodule_one.ko
mymodule_two.ko
mymodule_three.ko
mymodule_four.ko
mymodule_five.ko
mymodule_six.ko
mymodule_seven.ko
mymodule_eight.ko
mymodule_nine.ko
mymodule_ten.ko
mymodule_elevan.ko
mymodule_twelve.ko
mymodule_thirteen.ko

/etc/modules-load.d# cat 03-wifi.conf
brcmfmac.ko
brcmutil.ko
cfg80211.ko
compat.ko

Here's the condition dump from initctl cond dump

1     init                     on      <task/modprobe.compat.ko:17/success>
1     init                     on      <task/modprobe.cfg80211.ko:16/success>
1     init                     on      <task/modprobe.brcmutil.ko:15/success>
1     init                     on      <task/modprobe.brcmfmac.ko:14/success>
1     init                     on      <task/modprobe.mymodule_thirteen.ko:13/success>
1     init                     on      <task/modprobe.mymodule_twelve.ko:12/success>
1     init                     on      <task/modprobe.mymodule_elevan.ko:11/success>
1     init                     on      <task/modprobe.mymodule_ten.ko:10/success>
1     init                     on      <task/modprobe.mymodule_nine.ko:9/success>
1     init                     on      <task/modprobe.mymodule_eight.ko:8/success>
1     init                     on      <task/modprobe.mymodule_seven.ko:7/success>
1     init                     on      <task/modprobe.mymodule_six.ko:6/success>
1     init                     on      <task/modprobe.mymodule_five.ko:5/success>
1     init                     on      <task/modprobe.mymodule_four.ko:4/success>
1     init                     on      <task/modprobe.mymodule_three.ko:3/success>
1     init                     on      <task/modprobe.mymodule_two.ko:2/success>
1     init                     on      <task/modprobe.mymodule_one.ko:1/success>

# ls /lib/finit/plugins/
bootmisc.so      netlink.so       resolvconf.so    tty.so
modprobe.so      pidfile.so       rtc.so           urandom.so
modules-load.so  procps.so        sys.so           usr.so

I'm using the latest version: bf72e6b9c87cefd1b06086644dfd4651792011fc

Here's the service I'm trying to use n my conf (this was working in a previous version before the task name change):

# WPA Supplicant
service [12345789] <net/wlan0/up,usr/wifi_enabled,usr/wifi_fw_user,task/modprobe.brcmfmac.ko/success> respawn pid:/run/wifi:wpa_supplicant.pid name:wifi :wpa_supplicant env:/etc/conf.d/wpa_supplicant:wlan0 pre:/usr/bin/pre-run-wpa_supplicant wpa_supplicant -iwlan0 $WPA_SUPPLICANT_OPTS -- WPA Supplicant (wlan0) Daemon

[troglobit]

Ah, of course, the modules-load plugin! I always forget about that one, because it was contributed by a 3rd party. Thank you for taking the time to respond so extensively! <3

Yes, that's the root of this behavior, along with #252. Turns out the modules-load plugin has the following hard-coded task stanza for all modules, which gives is what causes the indexing.

cgroup.init name:modprobe.%s :%d [2345] /sbin/modprobe %s %s -- Kernel module: %s

The :%d and fixes in #252 is what's causing the indexing you see.

I've prepared a workaround/extension of modules-load to add an optional configuration one-liner keyword per modules-load.d/file, tentatively called noindex, which would disable the :%d. Would that be sufficient to solve your use-case?

[hongkongkiwi]

yep that would work fine. Alternatively I could also use a compile time argument which changes the plugin. Any method is ok! :)

[troglobit]

Great, I'll add it later tonight! :)

[hongkongkiwi]

Any update for this part? I didn't see it in the latest pushed ver.

[troglobit]

Sorry, was stuck with a bit of overload at $DAYJOB, the latest push from my queue, as of 9b17ce0, contains fixes to the modules-load plugin that:

1. Add support for a set directive (for future expansion), that allows disabling indexing completely using set noindex anywhere in a file. This disables indexing for any subsequent module, but not the ones prior, in that file. Any other files will be unaffected, and will need set noindex too to disable indexing. Note, indexing is still counted in the background, so for any following file, indexing will pick up where it left off:

     01-foo.conf:          => name:id
        esp4.ko            => modprobe.esp4.ko:1
        set noindex
        deflate.ko         => modprobe.deflate.ko
     02-bar.conf:
        nls_iso8859-15.ko  => modprobe.nls_iso8859-15.ko:3
        nls_utf8.ko        => modprobe.nls_utf8.ko:4

2. Discard UNIX backup files, e.g. 01-foo.conf~