I was asking about installing a driver into the kernel snap and was successful, but I don’t really like the solution which was to compile the driver and use depmod as part of the build to install the module. This required forking the pc kernel branch to edit the snapcraft.yaml source. This isn’t a great solution because it is more difficult to have benefits of using a kernel snap, being managed by Canonical, lower ongoing maintenance burden, etc, for the sake of a single driver.
Would there be a way to add something similar to dkms to the kernel snap and allow modules/drivers to be loaded into the kernel from another snap?
I had discussed this with @ogra and @kyrofa earlier at the rally and we mentioned using load_module from an application snap, but after thinking about this I’m not sure this is a good solution as it creates a dependency from your application snap to the version of the kernel snap.
The interface kernel-module-control allows loading and removing kernel modules. Assuming you can do the rest inside your snap, this should work fine. The obvious caveat is that the external modules need to remain compatible with the kernel.
The interface kernel-module-control allows loading and removing kernel modules
Hang on, are these system kernel modules you mean? Reason I am asking is because for ages been thinking about making a tinc snap but always wondered how that would work if I could not load a tun.ko module from inside the snap.
Does kernel-module-control control that?
you should not need to do that at all, tun.ko should automatically be loaded by the kernel if you create a tun network device, so the network-control or netwok-setup-control interfaces should be completely sufficient here …
Furthermore, that isn’t what kernel-module-control is for. That interface is specifically for loading arbitrary modules into the kernel (and therefore a highly restrictive interface). For things like tun, if it isn’t loading for you automatically, then we can adjust network-control (not network-setup-control) to tell snapd to do this for you. The model for module loading is that if an interface exposes kernel functionality, that interface should be made to make sure the kernel module is loaded. Many kernel modules autoload, so not all of the interfaces that expose kernel functionality load modules, but if we missed something, file a bug/create a forum topic and we’ll get it fixed up.
Thanks. Sorry I didn’t see this was already an supported in snapcraft. I’m assuming then it can be done through normal methods, ie. insmod or load_module? I wasn’t sure if the actual method would be the same where the environments are confined.
I’m not sure how I feel about doing this as the specific module in question is the network interface. If I lose compatibility my capability for updates is gone. Glad to know it exists though. Would the suggested method for testing be what was referenced in the disable automatic updates thread where I would keep a device on edge channels to watch for incompatibilities?
