Add a Lenovo T495s reference client + an in-place-upgrade disko layout #10

New issue

Open

opened 2026-06-18 08:37:04 +00:00 by bram.buijs · 1 comment

bram.buijs commented

2026-06-18 08:37:04 +00:00

Collaborator

What's missing

There's one reference client today (dawo-hp-eb-850g7) and one disko layout
(single-nvme-luks, a fresh-install full-wipe). Two things I'd like to add:

A second hardware reference for an AMD ThinkPad (Lenovo T495s), so the
hardware-module pattern is exercised on more than one machine.
A disko variant (nvme-luks-ext4) that matches a machine's existing
storage and boot, so a host already running NixOS can switch to this config
without a wipe, same ext4 cryptroot, same lanzaboote /var/lib/sbctl
keys (so the signed chain and TPM2 unlock keep working). The full-wipe path
stays single-nvme-luks.

Plus rollout/update docs: provisioning with nixos-anywhere (using the existing
disko layout, optional nixos-facter hardware generation) and updates over the
already-wired deploy-rs nodes.

Files

modules/hardware/lenovo-t495s.nix,
modules/hosts/profiles/disko/nvme-luks-ext4.nix,
modules/hosts/clients/dawo-t495s.nix, docs/deploy.md.

The host imports profiles-dawo-generic and carries a commented opt-in block
for the hardening modules (nothing auto-on), consistent with the opt-in posture.

Question

Are a second hardware reference and the in-place-upgrade disko variant welcome
upstream, or would you rather keep only the full-wipe path in the generic repo?
(The Forgejo CI workflow from my branch is mirror-specific and will be left out
of the PR.)

## What's missing There's one reference client today (`dawo-hp-eb-850g7`) and one disko layout (`single-nvme-luks`, a fresh-install full-wipe). Two things I'd like to add: 1. A second hardware reference for an AMD ThinkPad (Lenovo T495s), so the hardware-module pattern is exercised on more than one machine. 2. A disko variant (`nvme-luks-ext4`) that matches a machine's *existing* storage and boot, so a host already running NixOS can switch to this config **without a wipe**, same ext4 cryptroot, same lanzaboote `/var/lib/sbctl` keys (so the signed chain and TPM2 unlock keep working). The full-wipe path stays `single-nvme-luks`. Plus rollout/update docs: provisioning with nixos-anywhere (using the existing disko layout, optional `nixos-facter` hardware generation) and updates over the already-wired deploy-rs nodes. ## Files `modules/hardware/lenovo-t495s.nix`, `modules/hosts/profiles/disko/nvme-luks-ext4.nix`, `modules/hosts/clients/dawo-t495s.nix`, `docs/deploy.md`. The host imports `profiles-dawo-generic` and carries a commented opt-in block for the hardening modules (nothing auto-on), consistent with the opt-in posture. ## Question Are a second hardware reference and the in-place-upgrade disko variant welcome upstream, or would you rather keep only the full-wipe path in the generic repo? (The Forgejo CI workflow from my branch is mirror-specific and will be left out of the PR.)

bram.buijs referenced this issue

2026-06-18 08:37:05 +00:00

feat: add Lenovo T495s reference client + in-place-upgrade disko #14

bram.buijs referenced this issue

2026-06-18 08:37:05 +00:00

feat: overheid baseline (hardening opt-in, users, T495s host, 26.05 pin) #7

rutger.putter commented

2026-06-18 10:48:03 +00:00

Collaborator

@bram.buijs wrote in #10 (comment):

Question

Are a second hardware reference and the in-place-upgrade disko variant welcome upstream, or would you rather keep only the full-wipe path in the generic repo? (The Forgejo CI workflow from my branch is mirror-specific and will be left out of the PR.)

I'd say specific hardware should not be part of the reference. The ideal location for hardware definitions should be nixos-hardware upstream. And any specific hardware profiles should be part of a organizational DAWO repo.

@bram.buijs wrote in https://code.overheid.nl/MinBZK/DAWO-NixOS/issues/10#issue-296: > ## [](#question)Question > > Are a second hardware reference and the in-place-upgrade disko variant welcome upstream, or would you rather keep only the full-wipe path in the generic repo? (The Forgejo CI workflow from my branch is mirror-specific and will be left out of the PR.) I'd say specific hardware should not be part of the reference. The ideal location for hardware definitions should be [nixos-hardware](https://github.com/NixOS/nixos-hardware) upstream. And any specific hardware profiles should be part of a organizational DAWO repo.

bram.buijs referenced this issue

2026-06-18 12:12:10 +00:00

feat(t495s): upstream T495 hardware, BTRFS disko, English deploy docs #20

rutger.putter referenced this issue from a commit

2026-06-18 12:53:33 +00:00

feat(t495s): use upstream T495 hardware, BTRFS disko, English docs

bram.buijs referenced this issue from a commit

2026-06-18 19:32:40 +00:00

revert daed6f81a189403e41d49df3d76cfb02d1de8ea5

bram.buijs referenced this issue

2026-06-18 19:33:03 +00:00

revert daed6f81a189403e41d49df3d76cfb02d1de8ea5 #32