Repository navigation
kryptik-update apply runs from the committed slot only - #238
Merged
Merged
Conversation
…ryptik writes them: kryptik-update status and rollback and kryptik-recover printed committed-slot and version-a/b as found, so whoever held the disk could put terminal sequences on root's screen or a false version in status build/service-scripts/esp-records.sh reads them for every tool that shows them: esp_slot gives a or b, esp_version a release's version (MAJOR.MINOR.PATCH as release-keys.sh numbers a release, then a development build's dated parts), each from a bounded first line, and unknown otherwise; a missing record reads as the caller says. kryptik-update status and rollback, kryptik-recover --status and its commit message, and the medium's install verify line use them; boot-check lists the file. boot-success's read of committed-slot is left as #226 has it, a or b or nothing. tools/tests/esp-records.sh covers the shapes (terminal sequences, words after a version, a second line, overlong, empty, absent); tools/tests/update-esp.sh runs the tool's own cmd_status on rewritten records.
…ooted from outside, which boot-success leaves running as uncommitted once its one reboot is spent, apply took the committed slot as its target, wrote over the one release known to boot, and judged a downgrade against the older release that ran from_committed reads the ESP's committed slot through esp_slot and refuses any other running slot, naming both and the way out (boot the committed slot, or kryptik-recover --commit-slot from the medium). cmd_apply asks it after the trial checks and before verifying the payload, so before any write. rollback is unchanged: from such a slot it arms the committed one, which is a way back. tools/tests/update-esp.sh runs the tool's own from_committed: it goes on from the committed slot, refuses another and a record that is no slot (without printing it), and unmounts the ESP each time; and it checks that cmd_apply asks before it verifies or writes.
DevomB
marked this pull request as ready for review
October 7, 2026 08:17
This was referenced Oct 7, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #234 (esp-records), whose
esp_slotit uses: merge #234 first. This PR's own change is the top commit, deee686.What was wrong: after #226, a slot booted from outside (a firmware entry that is not Kryptik's) is rebooted from once and then left running, reported as
uncommitted. On such a slot,kryptik-update applytookother_slot(running)as its target. That is the committed slot, the one release known to boot, and apply wrote over it. It also judged a downgrade against the older release that runs, not the committed one. #226's body named this gap and left it.What changed:
from_committedintools/update/kryptik-updatereads the ESP's committed slot throughesp_slot(a or b,unknownotherwise) and refuses any other running slot. The refusal names both slots and the way out: boot the committed slot, orkryptik-recover --commit-slotfrom the medium.cmd_applyasks after the trial checks and before verifying the payload, so before any write.rollbackis unchanged: from such a slot it arms the committed one, which is a way back. The design doc's apply refusals say so.How it is proven:
tools/tests/update-esp.shruns the tool's ownfrom_committedwith mount stand-ins:It also checks that
cmd_applyasks beforeverify_payloadand before the first write. The Distro run's update suite applies, rolls back, recovers and interrupts from the committed slot throughout, so none of those paths is refused.Distro run 37573812187 at deee686: every part green (install, update, integrity and zones, inputs, boot, desktop, production update-test 27/0; update-esp.sh 15/0 with the four new cases, esp-records.sh 22/0) except build/host-suites, whose one failing check is tools/tests/glibc-branch-patch.sh, fixed on main by #233 after this branch's base. CI green.