systemd-modules-load.service fails to start because it can't understand module arguments in /etc/modules, which it shouldn't even be reading

[Adam Novak]

[impact]

'man modules' claims that modules options can be provided in the /etc/modules file, but doing so causes systemd-modules-load.service to fail

[test case]

add a module with at least one option to the /etc/modules file and restart systemd-modules-load

see original description for more detail and example of service failure

[regression potential]

as this only changes a manpage, any regression would likely be in incorrect information provided to users, or some regression occurring due to replacement of the man file or upgrading of the package

[scope]

This was fixed in Debian by
https://salsa.debian.org/md/kmod/-/commit/676cb532b51be28cc19be6dd7fd8593ea5958e24

This is fixed already in Ubuntu focal and later.

[other info]

as this is a manpage-only correction, if this is sru'ed it should use block-proposed-bionic, or just be bundled with a real bugfix.

[original description]

My systemd-modules-load.service fails to start like this:

● systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; static; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2020-10-27 10:24:52 PDT; 4s ago
     Docs: man:systemd-modules-load.service(8)
           man:modules-load.d(5)
  Process: 23683 ExecStart=/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)
 Main PID: 23683 (code=exited, status=1/FAILURE)

Oct 27 10:24:52 octagon systemd[1]: Starting Load Kernel Modules...
Oct 27 10:24:52 octagon systemd-modules-load[23683]: Failed to find module 'vfio vfio_iommu_type1 vfio_pci vfio_virqfd'
Oct 27 10:24:52 octagon systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE
Oct 27 10:24:52 octagon systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'.
Oct 27 10:24:52 octagon systemd[1]: Failed to start Load Kernel Modules.

It looks like it's trying to interpret a whole module-and-arguments string as just a module name, and failing to load this.

By recursive grep of /etc, the only place it can be getting that string is /etc/modules:

$ sudo ag vfio_iommu_type1
[sudo] password for anovak:
modules
5:vfio vfio_iommu_type1 vfio_pci vfio_virqfd

The manpage for /etc/modules clearly says that the file may contain module names *and* arguments:

[anovak@octagon ~]$ man modules | grep Arguments
       The /etc/modules file contains the names of kernel modules that are to be loaded at boot time, one per line. Arguments can be given in the same line as the module name. Lines beginning with a

The manpage for systemd-modules-load.service doesn't mention /etc/modules, and says to see the manpage for modules-load.d(5). That manpage says that it only reads files from specific directories:

SYNOPSIS
       /etc/modules-load.d/*.conf

       /run/modules-load.d/*.conf

       /usr/lib/modules-load.d/*.conf

The manpage is clearly lying, and systemd-modules-load.service is clearly also reading /etc/modules. Moreover, it's misreading it, and not interpreting it according to the documented semantics of /etc/modules.

I was induced to create an /etc/modules like this by https://mathiashueber.com/windows-virtual-machine-gpu-passthrough-ubuntu/ but I'm not sure that it's actually getting used by anything, because lsmod shows some but not all of the options I specified.

[anovak@octagon etc]$ lsmod | grep "^vfio "
vfio 28672 2 vfio_iommu_type1,vfio_pci

Can systemd be made to stop reading /etc/modules so that it doesn't report failure when it doesn't understand lines with options? And is that file being read by something else in the system, or should I just remove it as a workaround to stop upsetting systemd?

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: systemd 237-3ubuntu10.42
ProcVersionSignature: Ubuntu 4.15.0-122.124-generic 4.15.18
Uname: Linux 4.15.0-122-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.9-0ubuntu7.18
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Oct 27 10:33:50 2020
InstallationDate: Installed on 2017-08-06 (1177 days ago)
InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
MachineType: System manufacturer System Product Name
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-122-generic root=UUID=5219a3ae-e14c-4f63-8f62-17cebc1af57a ro modprobe.blacklist=amdgpu usb_storage.quirks=0bc2:ab38: amd_iommu=on vfio-pci.ids=1002:67df
SourcePackage: systemd
UpgradeStatus: Upgraded to bionic on 2018-05-29 (882 days ago)
dmi.bios.date: 12/08/2018
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 4207
dmi.board.asset.tag: Default string
dmi.board.name: PRIME X370-PRO
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev X.0x
dmi.chassis.asset.tag: Default string
dmi.chassis.type: 3
dmi.chassis.vendor: Default string
dmi.chassis.version: Default string
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4207:bd12/08/2018:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnPRIMEX370-PRO:rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring:
dmi.product.family: To be filled by O.E.M.
dmi.product.name: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer
mtime.conffile..etc.systemd.journald.conf: 2018-05-28T15:25:25.223494
mtime.conffile..etc.systemd.resolved.conf: 2017-09-24T15:57:22.768472

[Adam Novak (interfect)]

This is an interaction between a symlink that systemd ships (as mentioned in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627949#10) and the kmod package (which ships the now-inaccurate /usr/share/man/man5/modules.5.gz).

[Dan Streetman (ddstreet)]

This is only a manpage error; options are no longer supported in the /etc/modules file.

This was fixed in Debian by
https://salsa.debian.org/md/kmod/-/commit/676cb532b51be28cc19be6dd7fd8593ea5958e24

This is fixed already in Ubuntu focal and later.

[Dan Streetman (ddstreet)]

I marked this as affecting kmod in bionic, but I don't think a manpage correction is worth an SRU for kmod. Possibly we could queue up this to ship with some other actual bugfix, or we could upload it with block-proposed-bionic to hold it in proposed until some other bugfix comes along.

[Mauricio Faria de Oliveira (mfo)]

Marking Bionic as Won't Fix as it's End of Standard Support (EOSS), and in Expanded Security Maintenance (ESM).
If you have an Ubuntu Pro subscription with Support, and would like a fix, please open a support ticket.