I want to pass options to the kernel module hid_apple by setting the appropriated string to NixOS option _boot.extraModprobeConfig_. This configuration is not taken into account, because the module is loaded during first stage boot phase.
in _nixos/modules/system/boot/stage-1.nix_ definition of initialRamdisk misses object /etc/modprobe.d/nixos.conf
Is there a reason, why it is not available in initrd?
the module is enabled in the kernel:
$ zgrep HID_APPLE /proc/config.gz
CONFIG_HID_APPLE=m
CONFIG_HID_APPLEIR=m
Is the following helpful: https://github.com/NixOS/nixos-hardware/blob/master/apple/macbook-pro-10-1.nix ?
If not, but you manage to find a solution please feel free to extend.
The driver hid_apple is part of initrd and it is loaded during the first boot phase without problems.
To configure a kernel module, you normally extend modprobe.conf. In NixOS you define boot.extraModprobeConfig. So far so good, but this do not work for modules, which are loaded during the first boot phase. In my special case the kernel module hid_apple, which I need for my Apple keyboard.
Sounds like it would make sense to include the contents of boot.extraModprobeConfig to the initrd as well.
I have root on ZFS, and my
boot.extraModprobeConfig = "options zfs zfs_arc_max=4194304";
seems to be ignored because of this as well.
Any progress?
Looks like a dupe of https://github.com/NixOS/nixpkgs/issues/20906
I just ran into this for another module and had to move some options to kernelParams as a result. It would be nice if a proper solution could be found...
So it looks like there's a story behind this way back from 2014: It was fixed in #3505 and then quickly reverted again: 4a4c051a95b6b8da3a13d7955087e915e6dd4bf7. The problem appears to be that options firmware_class path=/nix/store/...-firmware/lib/firmware can be set in modprobe.conf, which I guess blows up the initrd closure/image?
Hello, I'm a bot and I thank you in the name of the community for opening this issue.
To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.
The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.
If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them.
Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel.
180 days
That seems kind of short..? that's barely even a single nixos release cycle... Bugs don't just magically get fixed if they're ignored for a few months :<
180 days
That seems kind of short..? that's barely even a single nixos release cycle... Bugs don't just magically get fixed if they're ignored for a few months :<
We won't close them automatically. It just a reminder to have a look at the issue again and see if it was fixed or still applies. Sometimes issue don't get not closed also the issue has been resolved.
Most helpful comment
Sounds like it would make sense to include the contents of
boot.extraModprobeConfigto the initrd as well.