Grub command line persistence

I was attempting use NixOS on my laptop the other day, and I was able to install everything just fine, however I ran into an issue that I couldn’t figure out through the documentation.

My laptop has a hardware issue with the keyboard, where it will not work upon booting, that is: no keys work, the LEDs don’t light up, nothing. Sometimes it will start working after a few key presses, sometimes it won’t work for an hour.

The solution that I’ve defaulted to after a ton of research has been to set my bootloader (usually grub) command line to include i8042.dumbkbd=1, which essentially gets rid of the problem, although it causes the LEDs to stop working, at least I can use my laptop.

Since NixOS has an immutable filesystem, I can’t just edit /etc/default/grub like I usually would. And after searching through all of the documentation for grub related settings (the ones that are available with in your configuration.nix file), I was unable to find a solution for persistently setting my grub command line.

I of course could avoid the issue by manually editing my grub command line every single time I boot my laptop, but I hope you all can understand that I’m not interested in doing that.

If anyone can help me out/point me in the right direction, I’d really appreciate it. Thank you!

You’re looking for this option: NixOS Search

I’m curious if your keyboard could be fixed by some nonstandard module, have you checked nixos-hardware?

Edit: Right, looks like you could fix it with this patch: GitHub - yescallop/atkbd-nogetid: Fixes failed keyboard initialization on some Lenovo Yoga / XiaoXinPro / IdeaPad (14", Intel) laptops.

That’d look something like this:

boot.kernelPatches = [{
  # Fixes keyboard init issues
  name = "atkbd-nogetid";
  extraPrefix = "kernel/drivers/input/keyboard";
  patch = pkgs.fetchpatch {
    name = "atkbd-nogetid.patch";
    url = "https://raw.githubusercontent.com/yescallop/atkbd-nogetid/main/patches/atkbd.c.diff";
    hash = pkgs.lib.fakeHash;
  };
}];

You may have to patch the patch though, as it seems to be prepared for arch’s kernel build system, which apparently has some kind of metadata file that tells the build system which folder to apply the patch to. Kind of weird, patch files have a standard for including that metadata.

I added an extraPrefix that might fix that, who knows.

Whether that’s worth the effort of rebuilding the kernel and/or having merge rejects every once in a while is your call.

Certainly something that could be added to nixos-hardware.