Better hardware-detection with nixos-facter

Links
1

We have all used nixos-generate-config, and it has provided us with good service over the years. With our new project, nixos-factor (mostly written by @brianmcgee), we are exploring a new area by providing more extensive raw hardware information in a JSON hardware report and doing the actual configuration in a NixOS module. Our goal is to replace a significant portion of the manual configuration currently done in nixos-hardware profiles, leaving only hardware quirks that cannot be auto-detected.

Check out our blog post for details: Introducing NixOS Facter - Clan Documentation

36 Likes
2

Can you say a little about how this scans the system?

My first reaction was to think about GitHub - linuxhw/hw-probe: Probe for hardware, check operability and find drivers.

(It would be lovely to (optionally) contribute working hardware configs to databases like https://linux-hardware.org/ and https://drmdb.emersion.fr)

1 Like
3

When I first started, I tried wrapping libusb, etc. It didn’t take me long, though, to stumble across GitHub - openSUSE/hwinfo: Hardware information tool, which does all the heavy lifting on the hardware scanning side and exposes a C lib. So I decided for a few reasons it was better to wrap hwinfo for the hardware section you see in the report.

As for virtualisation detection, I’ve ported most of systemd/src/basic/virt.c at 7fe0ea2eadc5ea38529453d5811112e473b744bd · systemd/systemd · GitHub to Go (container detection is the last bit to implement).

The idea is to start building up hardware reports for things like Hetzner machine types, laptop models and so on. We could even have an activation script that runs the scan on startup and shouts if there are any changes when compared to the report that was used in the NixOS config.

I can see a future where these reports could be submitted to various hardware databases too.

6 Likes
4

Where do the reports live for common stuff ?

I’m on AMD 13 framework. I’m down to try to see what this differs from NixOS-hardware setup.

5

We haven’t started compiling reports yet; we’re still evolving the report format and increasing the coverage of what it captures. Once it steady states, which I hope to reach in the next few weeks, we can start compiling hardware reports.

I’ll drop an update on Discourse when we get to that point.

1 Like
6

Feel free to reach out to me privately later to try it.
Would love to make nix-home/machines/nyx/hardware-configuration.nix at 36b2cbc062668259bd5339a5ee0ab075318d8225 · fzakaria/nix-home · GitHub more accurate and easier to parse via a JSON hardware config.

1 Like
7

Could this also be used to do things like automatically enable hardware.rasdaemon.enable on hosts that have ECC memory?

8

Could this also be used to do things like automatically enable hardware.rasdaemon.enable on hosts that have ECC memory?

Yes :slight_smile:

I recently added smbios info to the report. Here’s an excerpt from one of our Hetzner servers:

    {
      "type": "memory_array",
      "handle": 33,
      "location": {
        "value": 3,
        "name": "Motherboard"
      },
      "usage": {
        "value": 3,
        "name": "System memory"
      },
      "ecc": {
        "value": 5,
        "name": "Single-bit"
      },
      "max_size": 268435456,
      "error_handle": 65534,
      "slots": 8
    },
    {
      "type": "memory_device",
      "handle": 34,
      "location": "CPU1_DIMM_A1",
      "bank_location": "NODE 0",
      "manufacturer": "Samsung",
      "asset_tag": "CPU1_DIMM_A1_AssetTag",
      "part_number": "M321R4GA3BB6-CQKVS",
      "array_handle": 33,
      "error_handle": 65534,
      "width": 64,
      "ecc_bits": 16,
      "size": 33554432,
      "form_factor": {
        "value": 9,
        "name": "DIMM"
      },
      "set": 0,
      "memory_type": {
        "value": 34,
        "name": "Other"
      },
      "memory_type_details": [
        "Synchronous"
      ],
      "speed": 4800
    },
9

Update: NixOS Facter: declarative hardware configuration for NixOS

2 Likes
10

Can this be eventually upstreamed to nixpkgs itself and make nixos-generate-config redundant/deprecate that with this?

11

That’s one of the milestones:

The current set of NixOS modules replicates some of the behaviour found in nixos-generate-config. In the long term, we hope to close the functional gaps and upstream.

1 Like
12

Huh, I wonder if it’ll require an RFC to get this fully in, considering it’s a pretty big change (also would this deprecate NixOS-hardware?) Ideally, if it so, this should go into the nixpkgs instead of being spun up into another repo like nixos-hardware was.

13

I don’t think nixos-hardware would fully go away, but could be simplified a lot. We want to use sku information to automatically import the right machine profiles from nixos-hardware.

14

We already have an RFC for this. It was closed back than as I didn’t actually work on it: [RFC 0070] Merge nixos-hardware in to nixpkgs (#70) by Mic92 · Pull Request #70 · NixOS/rfcs · GitHub

15

What would happen to nixos-facter-modules?