Handling /etc/modprobe.d and module load order

Amit

unread,

Sep 13, 2012, 3:30:02 PM9/13/12

to

Hello,

I am using debhelper 9.20120115 and would like some advice on bundling
/etc/modprobe.d/package.modprobe and /etc/modules.

1. I am currently using dh_installmodules to install package.modprobe.
However, I noticed that the automated debhelper commands in
postins/postrm don't run update-initramfs. Is updating initramfs not
necessary?

2. I also need to specify module load order so I am bundling
/etc/modules. However, there doesn't seem to be a debhelper script
to handle /etc/modules.

I searched the list archives and found conflicting arguments regarding
the use of update-initramfs after updating /etc/modules or
/etc/modprobe.d/.

Thanks for any help,
Amit

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/loom.2012091...@post.gmane.org

Ben Hutchings

unread,

Sep 13, 2012, 5:00:02 PM9/13/12

to

On Thu, 2012-09-13 at 19:19 +0000, Amit wrote:
> Hello,
>
> I am using debhelper 9.20120115 and would like some advice on bundling
> /etc/modprobe.d/package.modprobe and /etc/modules.
>
> 1. I am currently using dh_installmodules to install package.modprobe.
> However, I noticed that the automated debhelper commands in
> postins/postrm don't run update-initramfs. Is updating initramfs not
> necessary?

That depends on what are you trying to do.

> 2. I also need to specify module load order so I am bundling
> /etc/modules. However, there doesn't seem to be a debhelper script
> to handle /etc/modules.

Don't ever touch /etc/modules, that's for the user/administrator. You
can load modules from an init script if there is really no better way.

> I searched the list archives and found conflicting arguments regarding
> the use of update-initramfs after updating /etc/modules or
> /etc/modprobe.d/.

/etc/modules is used by the init scripts, not the initramfs.
/etc/modprobe.d *does* get copied to the initramfs and I think you're
right that update-initramfs should generally be called after it's
updated. Perhaps initramfs-tools should have a file trigger for it,
though.

Ben.

--
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.

signature.asc

Michael Biebl

unread,

Sep 13, 2012, 5:20:01 PM9/13/12

to

Am 13.09.2012 22:53, schrieb Ben Hutchings:
> On Thu, 2012-09-13 at 19:19 +0000, Amit wrote:

>> 2. I also need to specify module load order so I am bundling
>> /etc/modules. However, there doesn't seem to be a debhelper script
>> to handle /etc/modules.
>
> Don't ever touch /etc/modules, that's for the user/administrator. You
> can load modules from an init script if there is really no better way.

You can use a modules-load.d file [1]. While the idea originally comes
from systemd, it has also been implemented in the kmod (f.n.a.
module-init-tools) package.

Cheers,
Michael

[1] http://0pointer.de/public/systemd-man/modules-load.d.html

signature.asc

Amit

unread,

Sep 13, 2012, 5:50:02 PM9/13/12

to

Ben Hutchings <ben <at> decadent.org.uk> writes:

[snip]

> > 1. I am currently using dh_installmodules to install package.modprobe.
> > However, I noticed that the automated debhelper commands in
> > postins/postrm don't run update-initramfs. Is updating initramfs not
> > necessary?
>
> That depends on what are you trying to do.

Trying to load usbhid and passing a quirks parameter so that it ignores
a specific device. Then, I have my own kernel module to control that
device.

>
> > 2. I also need to specify module load order so I am bundling
> > /etc/modules. However, there doesn't seem to be a debhelper script
> > to handle /etc/modules.
>
> Don't ever touch /etc/modules, that's for the user/administrator. You
> can load modules from an init script if there is really no better way.
>

OK. So I blacklist the modules in package.modprobe. And then load them
in the order I want in package.init by just calling modprobe?

> > I searched the list archives and found conflicting arguments regarding
> > the use of update-initramfs after updating /etc/modules or
> > /etc/modprobe.d/.
>
> /etc/modules is used by the init scripts, not the initramfs.
> /etc/modprobe.d *does* get copied to the initramfs and I think you're
> right that update-initramfs should generally be called after it's
> updated. Perhaps initramfs-tools should have a file trigger for it,
> though.
>

I ran some tests, and we definitely do need to update initramfs after
any changes under /etc/modprobe.d.

Thanks for reply.

Amit

unread,

Sep 13, 2012, 6:00:01 PM9/13/12

to

Michael Biebl <email <at> michaelbiebl.de> writes:

>
> Am 13.09.2012 22:53, schrieb Ben Hutchings:

[snip]

> > Don't ever touch /etc/modules, that's for the user/administrator. You
> > can load modules from an init script if there is really no better way.
>
> You can use a modules-load.d file [1]. While the idea originally comes
> from systemd, it has also been implemented in the kmod (f.n.a.
> module-init-tools) package.
>

Thanks. Looks like this is only implemented in the newer debian systems
correct?

Couldn't find it in squeeze.

> Cheers,
> Michael
>
> [1] http://0pointer.de/public/systemd-man/modules-load.d.html
>
>

Ben Hutchings

unread,

Sep 13, 2012, 7:20:01 PM9/13/12

to

On Thu, 2012-09-13 at 21:47 +0000, Amit wrote:
> Ben Hutchings <ben <at> decadent.org.uk> writes:
>
> [snip]
>
> > > 1. I am currently using dh_installmodules to install package.modprobe.
> > > However, I noticed that the automated debhelper commands in
> > > postins/postrm don't run update-initramfs. Is updating initramfs not
> > > necessary?
> >
> > That depends on what are you trying to do.
>
> Trying to load usbhid and passing a quirks parameter so that it ignores
> a specific device. Then, I have my own kernel module to control that
> device.

What is this driver?

> > > 2. I also need to specify module load order so I am bundling
> > > /etc/modules. However, there doesn't seem to be a debhelper script
> > > to handle /etc/modules.
> >
> > Don't ever touch /etc/modules, that's for the user/administrator. You
> > can load modules from an init script if there is really no better way.
> >
>
> OK. So I blacklist the modules in package.modprobe. And then load them
> in the order I want in package.init by just calling modprobe?

Unless you're doing something very unusual, you let udev load the module
automatically based on its device ID table.

> > > I searched the list archives and found conflicting arguments regarding
> > > the use of update-initramfs after updating /etc/modules or
> > > /etc/modprobe.d/.
> >
> > /etc/modules is used by the init scripts, not the initramfs.
> > /etc/modprobe.d *does* get copied to the initramfs and I think you're
> > right that update-initramfs should generally be called after it's
> > updated. Perhaps initramfs-tools should have a file trigger for it,
> > though.
> >
>
> I ran some tests, and we definitely do need to update initramfs after
> any changes under /etc/modprobe.d.

Yes, usbhid is included in the initramfs so any options need to be in
there too.

Ben.

--
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky

signature.asc

Amit

unread,

Sep 17, 2012, 12:50:01 PM9/17/12

to

Ben Hutchings <ben <at> decadent.org.uk> writes:

> >
> > Trying to load usbhid and passing a quirks parameter so that it ignores
> > a specific device. Then, I have my own kernel module to control that
> > device.
>
> What is this driver?

It is a driver for a PIC microcontroller board. I was using usbhid but
there was a bug that I couldn't work around. So I am bundling a custom
kernel module. I need to blacklist that device from usbhid otherwise it
tries to control the device.

> >
> > OK. So I blacklist the modules in package.modprobe. And then load them
> > in the order I want in package.init by just calling modprobe?
>
> Unless you're doing something very unusual, you let udev load the module
> automatically based on its device ID table.
>

I haven't thought of this. How does this work in the case when usbhid
already has the device in its device ID table.

Thanks for your help.

Amit

Ben Hutchings

unread,

Sep 17, 2012, 11:40:02 PM9/17/12

to

On Mon, 2012-09-17 at 16:46 +0000, Amit wrote:
> Ben Hutchings <ben <at> decadent.org.uk> writes:
>
> > >
> > > Trying to load usbhid and passing a quirks parameter so that it ignores
> > > a specific device. Then, I have my own kernel module to control that
> > > device.
> >
> > What is this driver?
>
> It is a driver for a PIC microcontroller board. I was using usbhid but
> there was a bug that I couldn't work around.

A bug in which?

> So I am bundling a custom
> kernel module. I need to blacklist that device from usbhid otherwise it
> tries to control the device.
>
> > >
> > > OK. So I blacklist the modules in package.modprobe. And then load them
> > > in the order I want in package.init by just calling modprobe?
> >
> > Unless you're doing something very unusual, you let udev load the module
> > automatically based on its device ID table.
> >
>
> I haven't thought of this. How does this work in the case when usbhid
> already has the device in its device ID table.

They both get loaded.

Ben.

> Thanks for your help.
>
> Amit
>
>

--

Ben Hutchings
The world is coming to an end. Please log off.

signature.asc

Ian Jackson

unread,

Sep 18, 2012, 6:40:02 AM9/18/12

to

Ben Hutchings writes ("Re: Handling /etc/modprobe.d and module load order"):

> On Mon, 2012-09-17 at 16:46 +0000, Amit wrote:
> > It is a driver for a PIC microcontroller board. I was using usbhid but
> > there was a bug that I couldn't work around.
>
> A bug in which?

I assume a bug in the board which Amit wanted to work around by using
a stunt version of the usbhid driver.

> > I haven't thought of this. How does this work in the case when usbhid
> > already has the device in its device ID table.
>
> They both get loaded.

And how should Amit arrange that the stunt driver, not normal usbhid,
gets control of the device ?

Ian.

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20568.20278....@chiark.greenend.org.uk

Amit

unread,

Sep 18, 2012, 1:30:02 PM9/18/12

to

Ian Jackson <ijackson <at> chiark.greenend.org.uk> writes:

>
> Ben Hutchings writes ("Re: Handling /etc/modprobe.d and module load order"):
> > On Mon, 2012-09-17 at 16:46 +0000, Amit wrote:
> > > It is a driver for a PIC microcontroller board. I was using usbhid but
> > > there was a bug that I couldn't work around.
> >
> > A bug in which?
>
> I assume a bug in the board which Amit wanted to work around by using
> a stunt version of the usbhid driver.

Yes, that is correct. The bug is in the firmware of the PIC
microcontroller.

>
> > > I haven't thought of this. How does this work in the case when usbhid
> > > already has the device in its device ID table.
> >
> > They both get loaded.
>
> And how should Amit arrange that the stunt driver, not normal usbhid,
> gets control of the device ?
>

This is main problem. Both the drivers try and control the device. The
only work around I could come up with was to pass a usbhid quirks to
ignore this specific board and then load the custom driver.

Thanks for the reply.

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/loom.2012091...@post.gmane.org

Marco d'Itri

unread,

Sep 18, 2012, 2:00:01 PM9/18/12

to

On Sep 18, Amit <amit....@gmail.com> wrote:

> This is main problem. Both the drivers try and control the device. The
> only work around I could come up with was to pass a usbhid quirks to
> ignore this specific board and then load the custom driver.

Actually there is a different solution:

# stop handling the device identified by VID and PID
ACTION=="add", SUBSYSTEM=="drivers", \
ENV{DEVPATH}=="/bus/usb-serial/drivers/usbhid", \
ATTR{remove_id}="xxxx yyyy"

# if no driver has claimed the interface yet, load your_driver
ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_interface", \
ATTRS{idVendor}=="xxxx", ATTRS{idProduct}=="yyyy", \
DRIVER=="", \
RUN+="/sbin/modprobe -b your_driver"

Or just:

echo 'xxxx yyyy' > /sys/bus/usb/drivers/usbhid/remove_id
modprobe your_driver

--
ciao,
Marco

signature.asc

Amit

unread,

Sep 20, 2012, 3:20:01 PM9/20/12

to

Marco d'Itri <md <at> Linux.IT> writes:

[snip]

>
> Or just:
>
> echo 'xxxx yyyy' > /sys/bus/usb/drivers/usbhid/remove_id
> modprobe your_driver
>

Tried this but it seems the PIC is buggier than I thought. There are
times when it disconnects and reconnects itself. As soon as the
reconnect happens, usbhid takes over the device. Thus, negating the
above command.

I ended up placing a line in */etc/default/grub* that passes the usbhid
quirks and have the postinst call update-grub. This passes the quirks to
kernel during boot so all seems well now.

Thanks,
Amit

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/loom.201209...@post.gmane.org