Repository navigation
boot-success forgets the firmware entries before it removes or sets aside the trial record - #262
Merged
Merged
Conversation
…s its source: boot-success's commit and kryptik-recover's commit and restore now compare, as the installer and kryptik-update already did boot-success copied the trial slot's kernel to BOOTX64.EFI.new, fsynced and renamed it without looking at what landed, and kryptik-recover did the same for the boot file and for the medium's kernel. A copy that read back wrong became a boot file Secure Boot refuses. Now the copy is compared with its source before the rename: a failed compare fails the commit and the trial stays, as a failed write already does, and recover stops before anything is committed. The installer compares BOOTX64.EFI and kryptik-update hashes its staged kernel. The boot-success fixture makes the copy read back wrong and expects the old boot file and record and the trial kept.
…side the trial record, so no BootNext an apply has just set is forgotten kryptik-update arms nothing while a trial record stands. boot-success removed the record (commit, interrupted arming) or moved it to trial.failed (a trial that did not boot, or came up unhealthy) and only then forgot the entries: an apply finishing in between would have its BootNext cleared and its trial recorded as failed at the next boot. Now the entries go first. The fixture records whether the trial record stood at each forget.
…ped from the page cache after its fsync, so the compare reads the ESP and not the copy still in memory From a non-author read: cmp right after sync -f read the cached pages, which says little more than cp's own status. dd iflag=nocache count=0 drops a file's clean pages, best effort; boot-success's and kryptik-recover's compares and kryptik-update's hash of its staged kernel now read what the ESP holds.
…drop before each kernel compare
…-success.sh, where main's shorter comments meet this branch's; forget_entries's comment keeps its line on running before the trial record goes
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.
Built on #261 (kernel-copy-compared, itself on #258). Until those land, the diff against main includes their commits. This PR's own change is the top commit, a9758aa.
What was wrong (an INFO from the update-chain re-read).
kryptik-update applyarms nothing while a trial record stands, but boot-success dropped the record before it forgot the firmware entries, in all four places:trial.failedfirst.So an apply finishing in the seconds between could have its
BootNextcleared and its trial reported as failed at the next boot. An apply hashes and writes gigabytes first, so this could not happen in practice, but the order made it possible.What changed.
build/service-scripts/boot-success.shforgets the entries first in all four places, and the comment onforget_entriessays why. The unhealthy path keepsforget_entries's result for its reboot decision, which is unchanged.How the run proves it.
tools/tests/boot-success.sh'skryptik-efibootstand-in records whether the trial record stood at each forget. The commit, unhealthy, did-not-boot and interrupted cases expect it did. Distro run 37883972227 boots trials and commits in the update suite.Merge with main: comments only in
boot-success.sh. 31849d1 merges main 6e06d94, whose shorter comments (#241) met this branch's two changed comment blocks.forget_entries's comment is main's plus this branch's line on running before the trial record goes. The code is identical to the pre-merge head 3f3bd5f, whose Distro run is 37883972227.