makeModulesClosure referencing nonsensical modules

[tadfisher]

Issue description

On a fresh rebuild of nixos-unstable, makeModulesClosure is referencing a nonsensical value as a module alias.

building '/nix/store/5fkzyqcs4rz4520m4xh9vasmj93bbgf8-kernel-modules-shrunk.drv'...
kernel version is 5.0.0
root module: xhci_pci
root module: ahci
...SNIP...
/nix/store/nlvbs1gn0jp99ms65mb2bc6i0xjd7www-kernel-modules/lib/modules/5.0.0/kernel/lib/zstd/zstd_compress.ko.xz
/nix/store/nlvbs1gn0jp99ms65mb2bc6i0xjd7www-kernel-modules/lib/modules/5.0.0/kernel/fs/btrfs/btrfs.ko.xz
modinfo: ERROR: Module alias use_blk_mq=y not found.
modinfo: ERROR: Module alias use_blk_mq=y not found.

Interestingly, dm_mod is now in the list of boot.initrd.kernelModules, even though I am not referencing that option in configuration.nix:

$ nixos-option boot.initrd.kernelModules
Value:
[ "btrfs" "crc32c" "dm_mod" ]

Default:
[ ]

So something appears to be parsing boot.kernelParams to include modules with flags referenced there in the initrd. Here is my boot.kernelParams setting:

 $ nixos-option boot.kernelParams
Value:
[ "dm_mod.use_blk_mq=y" "i915.fastboot=1" "splash" "loglevel=4" ]

Default:
[ ]

The wisdom of parsing boot.kernelParams for initrd modules aside, the parsing logic is likely incorrect and should discard the flag value rather than attempting to search for a module with that name.

This doesn't actually break the build for me, but any name collision between a flag and a real module could certainly do something the user doesn't expect.

Steps to reproduce

• Include the following in configuration.nix:

boot.kernelParams = [ "dm_mod.use_blk_mq=y" ];

• Run nixos-rebuild switch.
• Note the aforementioned errors in the log output.

Technical details

Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.

• system: "x86_64-linux"
• host os: Linux 4.20.13, NixOS, 19.09pre172038.5d3fd3674a6 (Loris)
• multi-user?: no
• sandbox: yes
• version: nix-env (Nix) 2.2
• channels(root): "nixos-19.09pre172038.5d3fd3674a6"
• channels(tad): ""
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

[tadfisher]

Actually, I am using LVM, so the idea that something is parsing boot.kernelParams to include dm_mod is likely a red herring.

[infinisil]

Nothing is parsing kernelParams, dm_mod is added to kernelModules in all non-containers, see

nixpkgs/nixos/modules/system/boot/kernel.nix

Lines 234 to 237 in 0eb2c19

	boot.initrd.kernelModules =
	[ # For LVM.
	"dm_mod"
	];

I feel like the error is somewhere in the https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/kernel/modules-closure.sh script, there the modinfo command happens.

[xaverdh]

Whatever the reason, I can confirm that kernelParams is somehow getting mixed up with the kernel modules. I have i915.enable_psr=1 in my kernelParams for example,and get
modinfo: ERROR: Module alias enable_psr=1 not found..

[xaverdh]

Ah ok, running
modprobe --config no-config -d /nix/store/id3ppcwynzpkavdrnjjy44fqanh02jci-linux-5.2.6/ --set-version '5.2.6' --show-depends i915
manually on my system yields an entry of the form
insmod /nix/store/id3ppcwynzpkavdrnjjy44fqanh02jci-linux-5.2.6//lib/modules/5.2.6/kernel/drivers/gpu/drm/i915/i915.ko.xz enable_psr=1
Note the enable_psr=1 part, which will get appended to the modules closure here.

[xaverdh]

I wonder if there is a specific reason why that script uses modprobe instead of parsing the output of
modinfo -b $kernel -F depends -k $version $module..

[tadfisher]

@xaverdh I just did a blame dive back to 2008: 3ee0b9b

It was added prior to that, when NixOS was using subversion, so I'm assuming it's been unchanged since the beginning of time.

[xaverdh]

I went with fixing the regex in that pr, since I'm not quite sure if there isn't a reason to be using modprobe. It does e.g. resolve aliases, which modinfo might not do?

[xaverdh]

I am not quite sure who to ping for that pr. shlevy or edolstra maybe?

[stale]

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the
   related code and @ mention them in a comment.
2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
   irc.freenode.net.

[xaverdh]

Well the bug is not fixed so this is not stale.

[xaverdh]

fixed by #92081