kldload 1.4.2 — Hardware

The desktop installer asks three questions

It used to ask nine. Eight of them were things you would answer the same way every time to get a working desktop, so they are now silent defaults: virtualisation, the Kubernetes lab, the AI assistant, monitoring, the ZFS lab and the mesh all install, because a desktop without them is not the product. What is left is what genuinely varies by machine — the NVIDIA driver (offered only when an NVIDIA GPU is actually present), Secure Boot, and whether to build VM golden images.

The web console also no longer starts on every boot. It was useful exactly once, during the install.

Firmware that was never actually installed

Both distributions shipped installs with large parts of the firmware tree empty, and nothing reported it. On Fedora, because version 43 split linux-firmware into per-vendor packages and this tree named a handful of wifi packages and nothing else. On Debian, because firmware-linux-nonfree depends on exactly two packages and lists every per-vendor set as a Recommends, while the install runs --no-install-recommends.

The microcode row is the one that matters most. An AMD machine booted with none at all, so Zenbleed- and Inception-class fixes never loaded. An Intel machine picked its files up through a different package and looked perfectly healthy, which is exactly why this went unnoticed for so long. The rest decides whether a laptop has working wifi, sound and a graphical console on first boot — a desktop with no GPU firmware is a black screen, not a slow one.

Codecs and video acceleration

Debian installed with no VA-API drivers and no libav, so hardware video decode was unavailable and a browser fell back to software for everything. Both are present now: 211 decoders and 7 VA-API drivers on Debian, 11 on Fedora. Both numbers were zero on Debian.

The boot chain

Secure Boot is off by default. It is still a checkbox and it still works, but an install no longer walks you through a key enrolment ceremony you did not ask for.

The encrypted-pool passphrase prompt is visible. It was being buried under kernel output on a quiet boot — the pool was waiting for a passphrase on a screen that gave no reason to type one.

A failed kernel re-sign no longer destroys the signature. The Secure Boot path strips and re-applies the kernel signature; if that failed, the ESP was left with an unsigned kernel and the machine would not boot. It now backs up first, verifies the result, and restores on failure. The host id is also pinned on every boot path — it was empty on the one entry a Secure Boot install uses, which made importing the pool a coin flip.

The kernel pin is derived, not written down

ZFS and NVIDIA are out-of-tree modules built against one specific kernel, so the kernel is held — 57 packages on a desktop install. That pin is now resolved at build time from what OpenZFS actually declares it supports, rather than a literal somebody updated by hand. A literal goes stale silently and lies about having been tested.

The pins were also being written underneath a mountpoint that had not been mounted yet, so the tool that set them could not see them afterwards. The system journal had the same defect, and its symptom was worse: it reported that it was recording while every boot was being erased.

Ansible proves itself on first boot

Ansible shipped configured and had never once run — the inventory listed the estate, the dropdown listed playbooks, and “is Ansible working?” was answered by reading configuration rather than by evidence. A playbook now runs unattended on first boot and writes a report naming every host it reached and, more usefully, every host it could not. A count on its own would have read as success while half the estate was unreachable.

Every machine records what built it

/etc/kldload-release carries the version, ISO name and build date, and — the half that turns a support report into a bug report — what the installer was actually told to do: which distro, profile and Secure Boot setting were requested. Asked “which ISO installed this machine?”, the only previous way to answer was to infer it from which packages happened to be present.

Diagnostics on both package managers

smartmontools, nvme-cli, ipmitool, OpenIPMI, lm_sensors, sg3_utils, lsscsi and usbutils ship on every profile. A machine that cannot report its own disk health is not a substrate you would trust with a pool, and without ipmitool a server's sensors, event log and power state are unreachable from inside the OS even though every driver is already in the kernel. They are inert on hardware with no BMC, so they ship everywhere rather than only on the server profile.

Validated on four installs

Both distributions, both boot paths, on real hardware: Fedora and Debian with Secure Boot and encryption, and both again with neither. All four finished with zero failed units, a healthy pool, a six-node Kubernetes cluster and identical codec counts. Rollback was exercised on both boot paths.

Full detail in CHANGELOG.md at the tag.