diff options
| author | Craig Jennings <c@cjennings.net> | 2026-05-22 20:58:01 -0500 |
|---|---|---|
| committer | Craig Jennings <c@cjennings.net> | 2026-05-22 20:58:01 -0500 |
| commit | 3165c50fed266fef0b388190296c149c0ae0ee47 (patch) | |
| tree | 6510ae19315f55eec78f0c618dbd737672b097f6 /docs | |
| parent | bed054f46e3b41aae0d599ed7fbc3e1e42d6ddd7 (diff) | |
| download | archangel-3165c50fed266fef0b388190296c149c0ae0ee47.tar.gz archangel-3165c50fed266fef0b388190296c149c0ae0ee47.zip | |
fix(test): run the ZFS-encryption check on the booted system
The ZFS native-encryption assertion lived in verify_install, which runs in the live ISO before reboot. But archangel exports zroot at the end of the install, so verify_install bails at "ZFS pool not found" and never reaches the check. It was dead code: the encrypted-config tests passed on the reboot path (entering the passphrase at ZFSBootMenu and booting is itself proof), while the explicit aes-256-gcm assertion gave false confidence by never running.
I moved it into verify_reboot_survival, which ssh's into the booted system where zroot is imported, so zfs get encryption zroot/ROOT actually returns aes-256-gcm and the assertion fires. Confirmed on a zfs-encrypt VM run: "ZFS encryption (aes-256-gcm) verified on running system."
Diffstat (limited to 'docs')
0 files changed, 0 insertions, 0 deletions
