Nixos-rebuild failed because of missing modules on kernel

Help
1

I was trying to just do weekly update as usual but this time i have an issue.

error: builder for '/nix/store/f5gl0cavfv1w49hcpqmva2cgaqgpwsiy-linux-zen-6.16.1-modules-shrunk.drv' failed with exit code 1;
       last 2 log lines:
       > Required modules: nvme xhci_pci ahci usbhid sd_mod ext2 ext4 crc32c xxhash_generic blake2b_generic sha256_generic ahci sata_nv sata_via sata_sis sata_uli ata_piix pata_marvell nvme sd_mod sr_mod mmc_block uhci_hcd ehci_hcd ehci_pci ohci_hcd ohci_pci xhci_hcd xhci_pci usbhid hid_generic hid_lenovo hid_apple hid_roccat hid_logitech_hidpp hid_logitech_dj hid_microsoft hid_cherry hid_corsair pcips2 atkbd i8042 dm-snapshot btrfs dm_mod
       > Can not derive a closure of kernel modules because no modules were provided.
       For full logs, run 'nix log /nix/store/f5gl0cavfv1w49hcpqmva2cgaqgpwsiy-linux-zen-6.16.1-modules-shrunk.drv'.

What the issue here? I already have the modules on the config.

  boot.initrd.availableKernelModules = [ "nvme" "xhci_pci" "ahci" "usbhid" "sd_mod" ];
2

does misused of nix-store --optimise caused the issues? I think i messed it up by adding the auto-optimise to the config then rebuild first then nix-store --optimise.

3

No. Please share your kernel-related config.

4

My kernel config is just normal as its, Zen Kernel with scx rusty. Nohing out of ordinary

  boot.initrd.availableKernelModules = [ "nvme" "xhci_pci" "ahci" "usbhid" "sd_mod" ];
  boot.initrd.kernelModules = [ "dm-snapshot" ];
  boot.kernelModules = [ "kvm-amd" ];
  boot.extraModulePackages = [ ];
  boot.kernelPackages = nixpkgsUnstable.linuxPackages_zen;
  scx = {
     enable = true;
     scheduler = "scx_rusty";
   };
5

So you’re mixing stable and unstable nixpkgs? :grimacing:

6

Well yes? Kernel and bottles only.

7

Just use kernel from stable, it’s the same version (6.16.1).

And in general, mixing stable with unstable is a bad idea.

8

Mixing stable and unstable is usually mostly fine. However, in this case, the kernel nix expressions changed, and kernel modules are now in a separate output, so a number of nixos internal code had to be changed to accommodate that. Obviously your stable nixos doesn’t have those changes, so can’t use the new kernel expressions from unstable.

2 Likes
9

No, it always introduces incompatibilities like this, causes issues with graphical apps, and at the very least adds an entire nixpkgs evaluation for little benefit. Beginners should be discouraged from doing this.

In general, if you need a newer version of something, override it - don’t add an entire nixpkgs instance for one package.

10

I said “usually mostly” not “literally always”.

11

And I’m saying it’s mostly bad. The times when it works fine are the exception to the rule.

12

It really isn’t, and issues with graphical applications have become much less problematic since the libgbm changes in nixos 25.05. Anyway, this is offtopic for this thread.

13

It’s not offtopic when that’s literally the cause of this issue… and the graphical app topic is also relevant as they mentioned using bottles. I’m discouraging bad practices that tend to frustrate newcomers and leave them with the idea that NixOS is broken :person_shrugging:

14

The topic at hand is that the kernel nix expressions in nixpkgs changed and that’s not compatible with older nixos releases. It has nothing to do with graphical applications or whether other use cases are compatible between stable and unstable. But since you insist, I’ll remind you that the reason graphical applications previously didn’t work across nixos versions was simply that host graphics drivers and applications were dynamically linked to different versions of libgbm. Since 25.05, this is no longer an issue as libgbm is now loaded dynamically from the host the same way that graphics drivers are. This design was specifically chosen to enable compatibility with packages built from completely different versions of nixpkgs.

It’s true that there will sometimes be issues with trying to use unstable packages on stable. In my experience this is not the most common result, but I can understand wanting to avoid the possibility altogether. I would not call it “bad practice” though.

3 Likes
15

I would probably say that doing so for the kernel specifically is bad practice, or at least a code smell. The same kernel versions are available for both stable and unstable, due to the specific policies around kernel versioning.

Unless there’s a change in the compiler that is somehow so impactful that you can measure it (let alone need it), you’re basically just opening yourself up to this kind of breakage for no reason whatsoever.

Maybe there’s some other scenario I can’t think of off the top of my head, but this is definitely inadvisable for most users.

Other packages, sure, most of the time it’ll be fine, but definitely point it out when you’re asking for help.

16

I didnt think this would spark a bit of debate lol. Anyway the issue is fixed by changing from unstable kernel to stable one (dumb me for didnt think its the first issue). Thank you @waffle8946 for pointing that out.

I am not new comer by any means (no i am not new linux user either). Its been a year (i think?) since first time i use NixOS. Yes, i mixed unstable and stable pkgs and i know the risk. I am just asking here if anyone have same issue or can pointing out if i am doing something wrong. Well atleast i learn something from this discussion :smile:

2 Likes
17

At the individual package level, if you can’t mix and match various versions of a package then the abstractions are probably too tight.

For instance packages works 100% to mix and match any commit of a particular package.
kernelPackages I would have thought it works like this… obviously there’s some more complexity with knowing the layout of the derivations which I guess has some rationale but a little unfortunate.

Thank you though for pointing to me the issue; it was causing me to pull some hair.