[DevomB]

The audit's install-secureboot:7. Only the install medium said whether Secure Boot checked the kernel (medium-banner.sh). The installed system never did, nor that the firmware was in setup mode, where any program running as root can enrol keys of its own. A machine left with Secure Boot off after a diagnostic boot, or with its keys cleared halfway through an enrolment, looked no different from one that enforces it.

build/service-scripts/secureboot-notice.sh is sourced by sysinit right after microcode-notice.sh, the same way. It writes one line to /run/issue.d/kryptik-secureboot.issue, which agetty prints above every login prompt:

Firmware	Line
SetupMode 1	the firmware did not check this kernel's signature, as it is in setup mode, where any program running as root can enrol keys of its own
SecureBoot 0	... as Secure Boot is off
no SecureBoot variable	the firmware gives no SecureBoot variable, so whether it checked this kernel's signature is unknown
SecureBoot 1, SetupMode 0	none, and an old line is removed

The advice after it comes from /etc/kryptik-image.json's signed_boot:

• A release (production): "add kryptik-sb.der to the firmware's db and turn Secure Boot on (the guide's section 1)".
• A development build, or no identity at all: "expected of a development build, whose key is never enrolled in real firmware". The line never asks for a development key to be enrolled (release-keys.sh).

Checks:

• tools/tests/secureboot-notice.sh covers every case above under sh, bash and dash, on stand-in efivarfs files and image identities, plus sysinit's . …; secureboot_notice || true. 19 pass, run here.
• The zones suite's secureboot-notice checks that the boot's line matches what the firmware's own variables say (its OVMF store is clean, so setup mode). On variables standing in for Secure Boot enforced, the line goes. The boot's own line is then restored.

The suites boot mostly with clean OVMF stores, so their serial consoles gain this line above each login prompt. I checked the suites' expectations near the prompt: medium-shell's banner match, update-test's own issue.d file, state-test's prompt ordering, and vm-drive's login: waits. None matches its text.

Base: zbook-batch-4 (#656), whose #620 and #654 also edit sysinit.sh. The services stage-04 step comes after the images' base, so no image is rebuilt. Tectonix: 5808 → 5812, no violations.