Repository navigation
The ESP's committed-slot and version records are fsynced before they are renamed into place, and boot-success writes no record nothing reads - #251
Merged
Conversation
…are renamed into place, and boot-success writes no record nothing reads On FAT only the rename is not atomic, so the kernels, BOOTX64.EFI and kryptik-recover's records are written to a new name, fsynced, then renamed. boot-success's committed-slot and kryptik-update's version-a/b skipped the fsync: a power cut after the rename could leave the record with a cluster that was never written, which the readers show as unknown and an apply then refuses as naming no committed slot. Both now fsync first. boot-success also copied version-X to version-committed on every commit. Nothing reads it, and kryptik-recover --commit-slot never updated it, so it could name the wrong release; it is no longer written.
…ed copy: the version and committed-slot records are written as the kernels are It named two renames as the only non-atomic steps, and the version file and committed-slot were renamed without an fsync before them.
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
1 participant
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.
What was wrong. On FAT only the rename is not atomic, so Kryptik writes the kernels,
BOOTX64.EFIand kryptik-recover's records (put) to a new name, fsyncs, and then renames. Two writers of one-line ESP records skipped the fsync:committed-slot, on every commitversion-a/version-b, on every applyA power cut between the rename and the later
synccould leave the record pointing at a cluster that was never written.esp_slot/esp_versionthen read it asunknown, and since #238 an apply refuses because the ESP names no committed slot. That can be repaired withkryptik-recover --commit-slot, but it should not happen.boot-success also copied
version-Xtoversion-committedon every commit. Nothing reads that file: no tool, suite or doc names it.kryptik-recover --commit-slotnever updated it, so after a recovery it could name the wrong release.What changed.
build/service-scripts/boot-success.sh:committed-slot.newis fsynced before the rename, andversion-committedis no longer written. A copy left on an installed ESP is inert.tools/update/kryptik-update:version-$target.newis fsynced before the rename.docs/design/boot-and-updates.md: the apply and commit steps say the version file andcommitted-slotare written like the kernels. Its closing line no longer names "the two renames" as the only non-atomic steps, since there were four.tools/tests/boot-success.sh: thesyncstand-in now logs to a file of its own, kept out of the exact call sequences the other checks compare. The commit case checks that the new record is fsynced under its temporary name.How the run proves it. CI's fixture step runs
tools/tests/boot-success.sh, which includes the new check. The Distro run boots through commits and applies in the update, install and integrity suites, so the changed lines run on a real FAT ESP. It will be dispatched once main's run 37645250378 has saved its caches.