Module blacklisting interface?

In the course of working out how to get a few different smartcard readers to work with pcscd (packaged as “pcsc-daemon” in the store now) to make reading government IDs, passports, NFC tags and smart cards easily possible on Ubuntu Core I ran into a good bunch of devices where the kernel module actually breaks the userspace USB driver.

The install instructions for many of these devices (not all of them indeed, else the kernel module would be pointless) do often start with “first of all create an /etc/norprobe.d/blacklist-pcscd.conf file containing the line ‘blacklist pn533_usb’” …

It struck me that we do not have any ability for users/customers to actually handle such module blacklisting (beyond giving full rw access to /etc/modprobe.d through a system-files interface or some such)

@jdstrand suggested i should start a discussion about how to handle such blacklists more cleanly…

A gadget default, an interface so a gadget could run a script, a system option you could use with snap set come to mind …

What is the best way forward here ?

It feels a bit like this is something that both the kernel snap and the system admin should have voices in, in that some kernel snaps may require a given module to be loaded in order for the kernel to work properly on the device, so I think a naive snap set system excluded-kernel-modules=[foo,bar] would have to somehow check with the kernel snap to make sure that it’s okay to exclude foo and bar, which also means that the kernel snap needs to convey this information to snapd somehow, perhaps through the snap.yaml specifically for snaps of type: kernel.

1 Like

What a coincidence, I’m trying to enable a new version of the board I’m working on, and I’ve found myself with a problem that might require blacklisting to solve/debug. Still have a lot of research to do, but I will be following this topic closely, as I would like an answer.

I am also interested in this. Was any progress made, or any future plans at all ?


well, if you need an interim workaround and use your own gadget, there is always the kernel commandline:

module_blacklist= [KNL] Do not load a comma-separated list of
                  modules.  Useful for debugging problem modules.

(from kernel parameters)

and for the other way around there is:

modules_load=, rd.modules_load=
                 Takes a comma-separated list of kernel modules to statically load during early boot. 
                 The option prefixed with "rd." is read by the initial RAM disk only.

(from systemd-modules-load.service)

The problem with that @ogra is, I don’t believe we can change the kernel commandline again yet on UC20. That was moved the snapd, and there is not yet a mechanism to change the it.

I’m waiting for that, and am very keen to have it :slight_smile: Discussed here in the context of changing the console param:

Cheers, Just

1 Like

ah, i forgot you are using x86 … (the arm gadgets are slightly more hackable in that regard)