If I add this to configuration.nix
:
boot.kernelPatches = [{
name = "roland-rc505";
patch = ./roland.patch;
}];
roland.patch
looks like this:
*** linux-5.15/sound/usb/implicit.c 2022-05-10 16:21:29.338255056 -0400
--- linux-5.15/sound/usb/implicit.c.roland 2022-05-10 16:30:46.590946394 -0400
***************
*** 74,84 ****
--- 74,86 ----
.type = IMPLICIT_FB_FIXED,
.ep_num = 0x84, .iface = 0 }, /* MOTU MicroBook II */
+ IMPLICIT_FB_SKIP_DEV(0x0582, 0x0171), /* BOSS RC-505 */
{} /* terminator */
};
/* Implicit feedback quirk table for capture: only FIXED type */
static const struct snd_usb_implicit_fb_match capture_implicit_fb_quirks[] = {
+ IMPLICIT_FB_FIXED_DEV(0x0582, 0x0171, 0x0d, 0x01), /* BOSS RC-505 */
{} /* terminator */
};
When included against nixos-25.05 the patchfile (which applies against almost any kernel version) is successfully applied, and a new kernel is successfully rebuilt on a following nixos-rebuild switch
, but a subsequent reboot doesn’t boot to the newly built kernel.
The way I’m determining that it’s not booting to the newly built kernel after the reboot is the build date returned via uname -a
. It is always Sun May 18
at the moment, I would expect it to be Thu May 22
.
To confirm that assumption, in one rebuild case against 25.05, I used:
boot.kernelPackages = pkgs.linuxPackagesFor (pkgs.linux_6_12.override {
argsOverride = rec {
src = pkgs.fetchurl {
url = "mirror://kernel/linux/kernel/v6.x/linux-${version}.tar.xz";
sha256 = "sha256-3wRqSJceQM4LLgA+flW2sefaKRISDrIW1dbIRQyc+C4=";
};
version = "6.12.30";
modDirVersion = "6.12.30";
};
});
And uname -a under the rebooted kernel indeed showed 6.12.30 (the default 25.05
kernel version is currently 6.12.29). The compile date showed Thu May 22
, which is what I would have expected from the builds I did against the default 25.05 kernel.
Is it normal to have to pin the kernel version like this to get a new kernel build via boot.kernelPatches
?