6

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?

millinon
  • 323
  • 3
  • 16
  • 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
    There is a bug report on Launchpad for this: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1535840 (still open without solution) – Philipp Wendler Sep 13 '19 at 11:06

2 Answers2

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

user57115
  • 71
  • 1
  • 4
  • 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 Jun 18 '19 at 10:57
  • 1
    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 Jun 18 '19 at 20:50
  • I'm planning to use Patroni, not the watchdog daemon... – Gert van den Berg Jan 16 '23 at 20:21
  • modprobe still loads the module, so I'm adding a ExecStartPre to the systemd unit – Gert van den Berg Jan 17 '23 at 11:22
0

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

$ sudo update-initramfs -u

Fy Ly
  • 1
  • 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: https://unix.stackexchange.com/questions/424599/is-update-initramfs-u-needed-after-adding-or-removing-a-module-with-modprobe – Fy Ly Nov 21 '18 at 00:49