Skip to content

fix(init): read the configured state-key mode before unlock so a node survives reboots #297

Closed

Description

@Bugs5382

Summary

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.
  • A regression test fails first. It covers an image default of tpm with nodeid configured, and the reverse. Each case boots, reboots and opens the volume, both at the unit level and in the QEMU image suite (the skipped Root upgrade step in test(e2e): boot the real image in QEMU as a Root and an Intermediate and run the product suite #296 is re-enabled).
  • Changing the mode on an installed node is either refused or documented. It must never silently leave the node unbootable.
  • docs/image-upgrade.md and the state-key docs describe the behaviour.

Notes

Related: #296 (where it was found), #264 (TPM reseal on upgrade).

Metadata

Metadata

Assignees

Labels

bugSomething isn't working.

Type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions