grubCryptodiskLegacyBios covers boot.loader.grub.enableCryptodisk on legacy
BIOS: GRUB itself decrypts /boot, entering the LUKS passphrase interactively,
and stage 1 then unlocks the root device with a keyfile embedded via
boot.initrd.secrets. Using a keyfile avoids a second, interactive passphrase
prompt in the initrd, whose wording differs between the scripted and systemd
stage 1 implementations, so the test passes under both (installer and
installer-systemd-stage-1).
fullDiskEncryption was marked broken. On the target boot GRUB's EFI
keyboard input appears to drop characters when the passphrase is typed at
the default speed, producing an "Invalid passphrase" error, so the disk
never unlocked. Type the passphrase more slowly and unbreak the test.
Assisted-by: Claude Opus 4.8
Move nixos/tests/grub.nix to nixos/tests/grub/basic.nix unchanged, and add
new GRUB boot tests under nixos/tests/grub/:
- hashed-password: GRUB user authentication with a
users.<name>.hashedPasswordFile (a grub-mkpasswd-pbkdf2 hash). The hash is
generated in a derivation and passed by store path (via toString) rather
than read at evaluation time, to avoid import-from-derivation. Kept separate
from basic so each login is exercised on its own VM boot rather than
multiplexed onto one menu.
- efi: boot through GRUB's EFI support.
- graphical: verify GRUB renders its menu in graphical (gfxterm) mode. A
marker string is baked into the splash image (which GRUB only draws in
gfxterm) and read back via OCR, so a silent fallback to text mode would
fail the test rather than pass it.
- mirrored-boots: verify GRUB is installed and configured on every path
in boot.loader.grub.mirroredBoots.
Assisted-by: Claude Opus 4.8
Fixes several correctness bugs primarily around modular services' recent
reload/notification options (#535695) and adds compliance coverage to guard them.
Fixes:
- `lib/services/service.nix`:
- the reload-conflict assertion had inverted polarity, so it fired on the
default configuration
- the `mkIf` guard on `process.reloadCommand` had a misplaced paren, applying
`!= null` to the `mkIf` result rather than to the condition
- `process.reloadSignal` derives `process.reloadCommand`, so the assertion
could not check `reloadCommand != null` -- that fired on every signal-only
service. The command is now derived at `mkDefault` priority and the
assertion is gated on `options.process.reloadCommand.highestPrio`, firing
only when the user also set `reloadCommand` explicitly.
- change `notificationProtocol` to a sub-module type
- `nixos/modules/system/service/systemd/service.nix`:
- `systemd.mainExecReload`'s default ran `escapeSystemdExecArgs` (a list
escaper) on the `nullOr str` `process.reloadCommand`; this threw
`expected a list but found a string` and would have mangled `$MAINPID`. It
now uses `process.reloadCommand` verbatim.
- the `Type` default read a non-existent
`config.serviceManager.notificationProtocol` instead of
`config.notificationProtocol`.
Tests:
Extend the modular-service compliance suite to guard the above:
- Portable (manager-agnostic) eval assertions: `reloadSignal` derives
`reloadCommand`, the conflict assertion does not fire on signal-only services
but does when both are set explicitly, and `notificationProtocol.systemd`/`.s6`
default to `false`.
- systemd-specific eval assertions: `serviceConfig.Type` (simple/notify) and
`serviceConfig.ExecReload` are asserted on the resolved host units. This
directly guards the `mainExecReload` fix, which threw before it.
- Runtime reload compliance test: a nested reloadable sub-service is started and
reloaded, asserting the service observed the reload (recorded a SIGHUP marker).
`callReload` receives the service's name path (the list of names from the
top-level service down to the target sub-service); each integration joins it
per its own unit-naming convention (NixOS dash-joins to the systemd unit name,
e.g. `reload-inner.service`). Keeping it a path list rather than a read-only
submodule option keeps the suite manager-agnostic.
- `doc/build-helpers/testers.chapter.md`: document `callReload`.
Follow-up to #535695.
Signed-off-by: cinereal <cinereal@riseup.net>
Assisted-by: Claude:claude-opus-4-8
immich is quite demanding which leaves it out of reach if you have one
core (e.g. on a laptop, when my EPYC P core was fine).
Make the test look more like the test for immich.
Robert Hensing