You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(init): read the configured state-key mode before unlock so a node survives reboots #297
A node whose state_key.mode is set in the machine config to something other than the image's build-time default can't come back from any reboot after its first boot. For example, nodeid on an image built with STATEKEY=tpm.
preUnlockStateKey (internal/init/configload.go, called from internal/init/run.go) resolves the state-key mode before the encrypted volume is open, and it reads only the ESP config stage. That stage exists only on the first boot. After that the function returns the zero StateKey, init falls back to the image's build-time mode, and OpenStateVolume tries the wrong unlock path. With panic=1 in the production command line, the node reboot-loops.
Found by the QEMU image suite in #296: the Root boots with state key mode: tpm from its config on a different-default image, fails OpenStateVolume on the first reboot, and loops. That suite skips the Root upgrade step until this is fixed.
This blocks v0.1.0: every reboot, upgrade and config-driven reboot in the validation matrix is affected for any node whose configured mode differs from its image default.
Acceptance criteria
After the first boot, the configured state-key mode is readable before unlock. It is persisted where init can read it without the volume, or derived from the LUKS2 header's token types, so a later boot uses the same mode the volume was sealed with.
Activity