Pin kernel version

1

Till the beginning of July 2024, NixOS came with a kernel version 6.6.32. Now we’re at 6.6.45 and my audio is broken. I am right now following the official instructions to install a custom kernel:

boot.kernelPackages = pkgs.linuxPackagesFor (pkgs.linux_6_6.override {
    argsOverride = rec {
      src = pkgs.fetchurl {
            url = "mirror://kernel/linux/kernel/v6.x/linux-${version}.tar.xz";
            sha256 = "0ibayrvrnw2lw7si78vdqnr20mm1d3z0g6a0ykndvgn5vdax5x9a";
      };
      version = "6.6.32";
      modDirVersion = "6.6.32";
      };
  });

This is no small task for my CPU. And I find it rather dumb, given that I can boot into an older generation that has this kernel, but nixpks only resolve kernel versions down to the minor version, not patch.

Is there no smarter way?

2

No if you’re using a different version of linux than what is exactly in the cache you will end up compiling it. No avoiding that.

3

And to be clear, the reason that this is a different kernel than the one from your older generation which has the same version number (assuming you meant it has the same patch version) is because the dependencies of the kernel derivation have changed, so this particular build isn’t cached.

1 Like
4

Both good points. I just wonder why I can’t select linux_6_6_32? Would that lead to too many versions in the cache? Or why isn’t that kept available?

Compilation is done by now, so it wasn’t too bad on my developer machine. And Audio is back!

5

Indeed having every patch version we had would be too much compilation, caching and maintenance. Patch bumps are normally not supposed to regress, so this happens rarely.

6

It’s both too many versions to have Hydra building all the time, and also just a bigger maintenance burden on nixpkgs contributors. And ideally, every new patch version is strictly superior to the last, so it is morally correct to only have the latest one. EDIT: Lol @MagicRB wrote basically the exact same thing.

If you want cached builds though, I have in the past run with boot.kernelPackages set to a linuxPackages from a different nixpkgs version. I don’t necessarily recommend this, since sometimes the version of packages in nixpkgs and the version of a kernel module are interconnected, so it can lead to issues.

1 Like
7

@ElvishJerricco at least they know neither of us is making it up :rofl:

8

Interesting idea. But I know the issues you’re referring to from installing kate via home-manager that used a different version of nixpkgs than NixOS. And KDE Plasma was installed via NixOS. That broke a lot. So I think I’ll avoid that if I can. Building myself did work within reasonable time, and shouldn’t need to be done too often, so I’ll stick with this. Thanks a lot for the explanations, though :slight_smile: