# Executing udev rules on boot:RUN executed before module load

## cz0

Hi folks!

I have National Instruments USB<->GPIB bridge. It is an USB board that need special procedure to became usable. I have linux_gpib package installed that provide two kernel modules: gpib_common and ni_usb_gpib. Besides, the gpib_config tool mast be executed before I can talk to any instrument on the GPIB bus. The trick is that board needs about 2 seconds after it was plugged into USB for internal initialization before gpib_config command will take effect. So, I have the following 99-gpib.rules udev rule that does the job perfect:

```
SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="3923", ATTR{idProduct}=="709b", RUN+="/bin/sh -c '/usr/bin/sleep 2; /usr/sbin/gpib_config --minor 0'"

KERNEL=="gpib[0-9]*", MODE="0660", GROUP="gpib"
```

The problem is it only work if I plug the board when host system is up and running. When I reboot with the dongle plugged in I can see both kernel modules loaded, but the board is unusable, meaning that gpib_config tool wasn't executed. If I run it by hand it work perfectly.

Since reboot scenario is more real, then plugging it while the system is running, I need the correct way to make udev do this on boot. Sure, I can write some init script that will check if the board is plugged and kernel modules are loaded and run the tool during loading process, but this is udev job cause it something to deal with hardware, I think. Any ideas?

UPD: udev executes RUN before module loading.Last edited by cz0 on Fri Nov 04, 2016 7:35 pm; edited 2 times in total

----------

## Tony0945

Maybe do a modprobe of the driver in /etc/local.d ?  I had a problem with a TV card and blacklisted the module, then modptobed it at the end of boot in /etc/local.d.  If you are using systemd, forget I responded.

----------

## cz0

I use OpenRC.

I tried to investigate this a little bit feather and found an interesting thing. First of all, in my system udev is at sysinit runlevel (which seem to be the right thing) and modules is at boot runlevel. As expected, udev starts before modules load, giving it zero chances to execute my rule properly.

I made an experiment: booted in interactive mode and before udev was started, I exited to console and stated modules (actually modules-load, but this is another question) manually and then exited console and started udev - my card initialized properly and was operational immediately after boot process finished.

So, the obvious question: is the boot is the correct runlevel for modules? Should I move it to sysinit?

Another question: my system is a couple years old and I have to scripts: modules and modules-load. The last one is the newest one and it loads more modules (well, at least virtualbox). Which should I use?

----------

## cz0

Well, it seems to be nothing about /etc/init.d/modules. udev seem to load appropriate kernel module by itself without any extra actions. But the problem is that udev executes RUN before modules get loaded.

UPD: confirmed. I kicked out both modules by rmmod and replaced the gpib_config command in the RUN parameter with lsmod to see module list at the moment command inside RUN is executed and nop, non of the gpib stuff is there. FAIL.

----------

## cz0

Heh, moved modules-load from boot to sysinit and udev now initialize my board correctly. Have no idea if this is a solution or just a crutch.

In my personal opinion udev should do this by itself: load correct modules and execute configuration utility. Dunno..

----------

## Tony0945

In the example I cited, the module was having trouble finding the firmware at boot time. But you don't have to blacklist it. Blacklisting just makes the boot faster.

/etc/modules.d files are executed last, so booting and sysinit are really done except for your locally defined stuff.   Files with suffix .start are executed in alphabetical order. Same for files with .stop at shutdown. Here's my cx18.start (executes after 000.start and baselayout1.start ).

```
modprobe ivtv &

modprobe cx18 &

```

  When the module loads, udev, eudev, or mdev will detect it and take their actions. If you don't want to blacklist the module then just put an rmmod at the start of the script just like you did manually.

I gave you the wrong name for blacklisting. I'm sorry. It's /etc/modprobe.d/blacklist.conf.

```
# NIC Kludge Stop r8169 loading so that r8168 will

blacklist r8169

#try to speed up udev

blacklist cx18

blacklist ivtv

#blacklist cx18-alsa

#blacklist ivtv-alsa

```

 cx18-alsa and ivtv-lsa are loaded by ivtv and cx18 so they don't need to be blacklisted if the parent is blacklisted.

The blacklist file prevents udev from loading the module.

----------

## cz0

Well, I don't have to load firmware to my board, it's modern one that has everything on board "from the box".

If rewind what I wrote above, the problem is in udev, that executes RUN stuff before actual module loading and interface creation therefore, gpib_config fails. I did another check: put 5 sec sleep before lsmod | grep gpib >> /root/log to RUN to see if udev even try to load modules before executing RUN thing - not a sausage!

So I see two possible solution:

1) move modules-load to sysinit runlevel and make it load modules before udev start, therefore udev executes gpib_config on top of preloaded modules and succeeds - this solution is now working$

2) somehow force udev to load modules first and after modules are loaded execute the RUN stuff - probably, this is the correct desired solution (just cause udev should deal with the modules on itself, I think), but I have no clue how to do this.

----------

## Tony0945

Well, I think my way is simpler, unless you need the device to boot, but it's certainly your choice. Since you are on OpenRC, have you tried using eudev instead of udev?

I see lots of complaints on this board that udev only plays well with systemd.

----------

## cz0

I don't understand your solution, actually. Why should I blacklist it and how then I will get the board working?

Can you point me out to the threads about this board, googling gives nothing particular.

P.S. The board is pesky.. I spent hours and hours understanding why the heck gpib_config is failing when executed on board connect before I guessed to introduce a delay. And I never seen a recipe with a delay, so it is probably version related to. But once modules are loaded and board is configured it seem to work rock stable.

----------

