That's what various other tools in hardware.* do, it's surpising if
`hardware.glasgow.enable` does not actually give you the `glasgow`
binary in `$PATH`.
This issue was observed after GNOME 48 -> 49 update.
User creation for gdm was changed, now it starts systemd user
services.
This causes issues for OTD and potentially other services, as
gdm-greeter user starts an OTD process creating a named pipe in /tmp
that acts as a lock file. When a user logs in, they also start a process
which exits with "Daemon is already running" and the gdm-greeter started
process exits.
Applying upstream patches that improve cleaning up the "lock file"
doesn't fix this issue, probably because there's not enough time between
stopping the first and starting the second process.
Fixes https://github.com/NixOS/nixpkgs/issues/469340.
This adds debugging tools for comparing system configurations with and
without facter-based hardware detection:
Example usage:
nix-build '<nixpkgs/nixos>' -A config.hardware.facter.debug.nvd
./result/bin/facter-diff
Builds on PR #466808 (camera support).
Part of incremental upstreaming from nixos-facter-modules.
The suspension/shutdown regression affects kernel 6.16 and later, not
just 6.16 specifically. Use versionAtLeast instead of equality check.
Also fix issue reference (372 was a separate issue) and typo.
The collectDrivers function was using lib.catAttrs which extracts
attribute values into a list. Since driver_modules is already a list,
this resulted in nested lists like [["i915"]] instead of ["i915"],
causing boot.initrd.kernelModules to fail with:
error: expected a string but found a list: [ "i915" ]
Restore the original foldl' implementation from nixos-facter-modules
that properly concatenates driver_modules lists into a flat result.
Add graphics_card and monitor entries to test data to catch this
regression.
Fixes: https://github.com/NixOS/nixpkgs/pull/466808#issuecomment-2749380083
This commit was created by a combination of scripts and tools:
- an ast-grep script to prefix things in meta with `lib.`,
- a modified nixf-diagnose / nixf combination to remove unused `with
lib;`, and
- regular nixfmt.
Co-authored-by: Wolfgang Walther <walther@technowledgy.de>
This adds automatic detection and configuration for Intel IPU6 cameras:
This is particularly useful for modern Intel laptops (11th-14th gen) with
integrated webcams that require the intel-ipu6 drivers. Auto-configuration
eliminates manual setup for these specialized devices.
Builds on PR #463457 (input peripherals).
Part of incremental upstreaming from nixos-facter-modules.
This adds automatic detection and configuration for input peripherals:
- bluetooth: Detects Bluetooth hardware and automatically enables
- fingerprint: Detects USB fingerprint devices using libfprint device database
Builds on PR #458177 (graphics).
Part of incremental upstreaming from nixos-facter-modules.
Add default value for features attribute in hasCPUFeature function
to handle CPU records that might not have a features field, preventing
errors when the report structure varies.
Add lib.mkIf condition checking if config.hardware.facter.reportPath != null
to all facter modules. This shortcuts the module effects when no facter
report is available, preventing unnecessary evaluation and potential errors
when the report is not provided.
This adds automatic graphics card configuration:
Builds on PR #456698 (virtualization & firmware).
Part of incremental upstreaming from nixos-facter-modules.
This adds automatic virtualization detection (virtualisation.nix) and firmware management (firmware.nix).
Builds on PR #455151 (networking).
Part of incremental upstreaming from nixos-facter-modules.
This adds automatic network configuration based on detected hardware:
- networking/default.nix: Auto-configure DHCP on physical interfaces
Detects Ethernet, WLAN, USB-Link, and generic network interfaces,
automatically enabling DHCP on each. Excludes loopback and mainframe
interfaces. Sets networking.useDHCP and per-interface useDHCP.
- networking/intel.nix: Intel WiFi firmware detection
Auto-enables firmware for Intel 2200BG and 3945ABG wireless cards
based on PCI vendor/device IDs.
- networking/initrd.nix: Network drivers in initrd
Loads network controller drivers when boot.initrd.network.enable
is set, enabling network boot scenarios.
Builds on PR #454847 (boot & storage).
Part of incremental upstreaming from nixos-facter-modules.
This adds automatic kernel module detection for boot-critical hardware:
- disk.nix: Detects and loads kernel modules for storage controllers
Auto-detects modules for: disk controllers, storage controllers,
and FireWire controllers (for FireWire-attached disks).
Modules are automatically added to boot.initrd.availableKernelModules.
- keyboard.nix: Detects USB controller drivers for keyboard support
Ensures USB HID drivers are loaded in initrd for keyboard access
during boot (critical for LUKS password entry, etc.).
Follow up to #454237.
Part of incremental upstreaming from nixos-facter-modules.
This adds foundational functionality for nixos-facter hardware detection:
- lib.nix: Internal helper functions for querying facter reports
- hasCpu/hasAmdCpu/hasIntelCpu: CPU vendor detection
- collectDrivers: Extract driver_modules from hardware entries
- toZeroPaddedHex: Format USB device IDs (for fingerprint matching)
- system.nix: Auto-detect nixpkgs.hostPlatform from facter report
Automatically sets the correct platform (x86_64-linux, aarch64-linux, etc.)
based on the hardware report, reducing manual configuration.
This builds on the base infrastructure added in PR #450303 and provides
the foundation for upcoming hardware detection modules (boot, networking,
graphics, etc.).
Part of the incremental upstreaming effort from:
https://github.com/nix-community/nixos-facter-modules
This is the first step to upstream nixos-facter-modules into
nixpkgs/nixos:
https://github.com/numtide/nixos-facter-modules/
We tried to stick close to the semantics nixos-generate-config + some
extra features. We choose a new prefix for hardware.facter to live in so
that existing users of nixos-facter-modules can continue using it while
the upstreaming is in progress.
The reason for upstreaming is to make it easier to have nixos-facter as
choice for hardware detection as part of our normal NixOS installation workflow.
Hardware from my experience takes many hands since it is hard to test
without having access to a large variety of hardware.
We hope that with nixos-facter we can reduce the boiler code required in
the nixos-hardware project and provide better out-of-the-box support,
even if a model has not been explicitly added to nixos-hardware.
I.e. unlike ubuntu we don't have support for detecting required GPU
drivers. We believe that nixos-hardware will be still required for some
vendor specific quirks, but we could in future automatically select the
profiles based on reported SKU from facter.
For more details watch the 2024 NixCon talk: https://www.youtube.com/watch?v=3H3YUqibC6c
