3

I am using Ubuntu 18.04. I'm trying to make a module load at boot; the module in question is iTCO_wdt. There are many questions about blacklisting a kernel module, but I am trying to whitelist one.

These are the steps I followed to try to make the module load at boot:

  1. Add iTCO_wdt to /etc/modules (which is symlinked to /etc/modules-load.d/modules.conf)
  2. Comment-out the blacklist iTCO_wdt line in /etc/modprobe.d/blacklist-watchdog.conf

I thought this would be sufficient, but syslog was still showing that the module was blacklisted:

systemd-modules-load[331]: Module 'iTCO_wdt' is blacklisted

After some investigation, I found that the module was also blacklisted in several maintainer-installed blacklist files located in /lib/modprobe.d:

$ grep -l 'blacklist iTCO_wdt' /lib/modprobe.d/*
/lib/modprobe.d/blacklist_linux_4.15.0-20-generic.conf
/lib/modprobe.d/blacklist_linux_4.15.0-23-generic.conf

I found that each file did affect the modprobe behavior, which is surprising, because I would not expect the linux_4.15.0.20-generic.conf file to affect the machine's behavior when linux_4.15.0.23-generic is the current kernel.

After commenting out the blacklist iTCO_wdt line in each of those files and rebooting, the module was automatically loaded, which is the desired behavior.

So, as I see it, there are a few ways I can make the module load even though it is blacklisted by a /lib/modprobe.d file:

  • manually comment-out the blacklist iTCO_wdt line in each file
  • load the module in my own script that runs at boot

The issue is that future updates might install new /lib/modprobe.d blacklist files, which might re-blacklist iTCO_wdt. With this consideration, it seems that my best option is the last one, although I really don't like it since it relies on my own script instead of the built-in module loading system.

Considering that I don't want to edit the /lib/modprobe.d files after every kernel update, what is the best way to permanently whitelist the iTCO_wdt module in the module loading system?

  • 1
    Not sure if this works: create an alias for iTCO_wdt (in a config that is parsed before the others...) – Nils Jun 21 '18 at 16:17
  • Thanks for the suggestion. I added the line alias iTCO_wdt my_wdt in /etc/modprobe.d/00-iTCO-alias.conf, and changed iTCO_wdt to my_wdt in /etc/modules, but syslog now shows systemd-modules-load[371]: Failed to find module 'my_wdt'. It seems that systemd-modules-load does not understand modprobe aliases? – millinon Jun 21 '18 at 16:34
  • 1
    @millinon the declaration goes the other way round: alias my_wdt iTCO_wdt (see man modprobe.d). – Stephen Kitt Jun 21 '18 at 16:38
  • Yikes, you're right. I switched it, and systemd-modules-load still reports that iTCO_wdt is blacklisted, even though I have the module listed as my_wdt in /etc/modules. – millinon Jun 21 '18 at 16:44
1

I encountered exactly this problem. The solution I found (by reading the watchdog docs at http://www.sat.dundee.ac.uk/psc/watchdog/Linux-Watchdog.html) was to edit the name of the kernel module (iTCO_wdt) into /etc/default/watchdog. So change the line:

watchdog_module="none"

to

watchdog_module="iTCO_wdt"

Didn't need to change any of the blacklisting files or indeed anything else - it just worked (on Mint 19.1)!

This, as noted in the docs, gets round the behaviour described by the OP and what seems to be regarded as a bug in systemd

  • As an addendum, the method in the Dundee docs for testing the watchdog resets does not appear to work! Sending SIGKILL to the watchdog daemon is supposed to terminate watchdog and trigger a reboot. Except from the syslog, it is clear that SIGKILL cause the wd_keepalive minimal daemon to start and continue the dog feeding. Hence no reboot! But sending the SIGSTOP signal to the watchdog does trigger a reboot. So there appear to be some differences between the current watchdog and the docs at Dundee. – user57115 yesterday
  • Thanks! This is some really useful information. However, it looks like the file /etc/default/watchdog doesn't exist on a new Ubuntu 18.04 installation, which to me suggests that it comes from the watchdog package. I assume this means that the watchdog daemon reads the file and then loads the module if it isn't already loaded. In my case, I'm not using the watchdog package - I'm using my own unprivileged daemon which expects the module to already be loaded. I could possibly make my daemon load the module, but that would probably require it to be a privileged process. – millinon 14 hours ago
0

Actually it's initrd (ramdisk) blocked this either. You need to update the blacklist conf in ramdisk as well:

$ sudo update-initramfs -u

  • Are you sure? I will test this, but I don't think that this is correct, because the module was loaded after I edited the files in /lib/modprobe.d/, without running update-initramfs. – millinon Nov 19 '18 at 17:37
  • Maybe, but it doesn’t hurt. Can decompose initrd and see what happened in the bushbox tiny root. Found a simple article: unix.stackexchange.com/questions/424599/… – Fy Ly Nov 21 '18 at 0:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.