Repository navigation
docs(spec): design for factory-reset wipe modes 2 and 3 - #23
Merged
JanZachmann merged 8 commits intoSep 18, 2026
Merged
Conversation
Signed-off-by: Jan Zachmann <jan.zachmann@conplement.de>
mlilien
reviewed
Aug 25, 2026
A wipe failure now maps to status Error instead of Warning, with the note in `error`. The reset still continues with reformat + restore. Correct the mode-2 justification (the legacy dd seek covers alignment and the ext4 superblock, not the fs label), replace the power-loss paragraph with the actual failure path, and drop the claim that mode 4 needs a customer bbappend to be testable. New section 4.1 collects the follow-ups from review: power-loss resume via a boot-env marker, storage-type guidance in the meta-omnect README, and the discard flavours. The README mode table fix becomes a required companion in omnect/meta-omnect#636. Signed-off-by: Jan Zachmann <50990105+JanZachmann@users.noreply.github.com>
The previous commit narrowed the "mkfs failed twice / restore partial failure" row from any wipe outcome to a failed wipe, which left today's mode-1 behaviour without a row. Split it into both cases and name what lands in `context` in each. Also state the reachable status set correctly (0, 2 or 4) and drop the claim about how ODS handles status values — that belongs in the review thread, not in a spec. Signed-off-by: Jan Zachmann <50990105+JanZachmann@users.noreply.github.com>
Mode 4 ran a customer-supplied hook as the wipe step. It is removed instead of ported: the one step the caller asked for would run code we neither build nor test, and modes 2 and 3 cover rotating disks and flash. A mode-4 trigger is now rejected as Invalid. This narrows the accepted trigger modes from 1-4 to 1-3, so `Mode4` has to go from the mode type in omnect-device-service and omnect-ui in the same release, and the meta-omnect README loses the mode-4 row and the custom-wipe paragraph. Both are recorded as required companions. Also drop the references to the private OS repo and its CI branch, which do not belong in a public repo. Signed-off-by: Jan Zachmann <50990105+JanZachmann@users.noreply.github.com>
JanZachmann
changed the title
"It cannot loop" read as if the recovery boot repeats the wipe. Name the two parts instead: the boot with the marker set reformats and never wipes again, and a failing reformat ends in today's path, where the init halts instead of rebooting itself. Also state that the preserved paths are lost in this case, because the backup lives in initramfs RAM. Signed-off-by: Jan Zachmann <50990105+JanZachmann@users.noreply.github.com>
HarryWaschkeit
left a comment
HarryWaschkeit
left a comment
There was a problem hiding this comment.
see my comments in existing threads
A marker that only says "wipe in progress" lets a recovery boot come up clean and report success although the preserved paths are gone. The recovery boot cannot reconstruct them: the preserve keys come from the trigger, which is cleared first, and resolve against files on the partition being wiped. Record that the marker also has to carry whether the backup held anything, and that the reported outcome follows from it. Note that the status reaches the cloud only if the device gets there, since the network configuration lives on the reformatted partition. Signed-off-by: Jan Zachmann <50990105+JanZachmann@users.noreply.github.com>
Raised in review of the mode-4 removal: a hook that runs after a successful reset so an application can pick up a signal on the next boot. It is not the removed wipe hook — it does not take over the wipe — and nobody has asked for it yet, so it stays an idea with its open questions. Signed-off-by: Jan Zachmann <50990105+JanZachmann@users.noreply.github.com>
The boot env key the init writes when a partition stays unmountable is never read and never cleared, and the status file ODS reads is written by a boot that in this case does not get that far. So the failure reaches nobody. Record the fix next to the power-loss bullet, because the recovery boot needs the same mechanism: it decides the outcome after the reset is over. Signed-off-by: Jan Zachmann <50990105+JanZachmann@users.noreply.github.com>
mlilien
approved these changes
Sep 18, 2026
HarryWaschkeit
approved these changes
Sep 18, 2026
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.
Summary
Design spec for the remaining factory-reset wipe modes: 2 (random overwrite) and 3 (block discard). The wipe runs between backup and reformat. A wipe failure never aborts the reset — reformat and restore still run and the device stays usable — but the result is reported as an error, because the caller asked for the data to be wiped and it was not. The implementation follows in a separate PR once this spec is approved.
Legacy mode 4 (custom wipe hook) is dropped instead of ported. It hands the wipe — the one step the caller asked for — to code we neither build nor test, and modes 2 and 3 cover rotating disks and flash. A mode-4 trigger is rejected as Invalid (status 1).
Deliberate changes vs the legacy script (details in section 1.1 of the spec):
ddseeking past the first 2048 bytes (partition alignment plus the ext4 superblock) — partitions are found by number, not label, and the filesystem is re-created afterwards, so the seek is not needed.BLKDISCARDioctl instead of mount +rm -rf+fstrim. This discards all blocks (including fs-journal remnants) and fixes the legacy bug where a failed mount counted as a successful wipe.The accepted trigger modes narrow from 1-4 to 1-3. The result schema does not change: no new fields or status codes, and a wipe failure reports the existing
Errorstatus (2) with the note in the existing free-texterrorfield, which follows the rule already in the code that a completed reset still reportsErrorwhen mkfs failed twice.Dropping mode 4 has to land in the same release everywhere the mode is known, otherwise the cloud or the local UI can still send a 4 that comes back as Invalid — which reads as a broken reset rather than a removed mode. Required companions:
Mode4out of the mode type in omnect/omnect-device-service and omnect/omnect-ui, and the meta-omnect README loses the mode-4 row, the custom-wipe paragraph and its bbappend instructions. That README also still describes the legacy tools for modes 2 and 3 and becomes wrong with this change, so the table rewrite belongs in the same place: omnect/meta-omnect#636.Section 4.1 records the follow-ups raised in review and deliberately kept out of this design: power-loss resume via a boot-env marker, including the rule that a recovery boot must not report success when the preserved paths were lost; reporting an outcome that no status file carried, since the boot env key the init writes for an unmountable partition is never read or cleared today; a hook called after a successful reset, which is a different feature from the removed wipe hook; storage-type guidance in the meta-omnect README; and the other discard flavours (
BLKZEROOUT,BLKSECDISCARD).Reason
Mode 1 is implemented; the remaining wipe modes are the missing part of the factory-reset port from the legacy initramfs scripts. The spec fixes the behaviour differences and the error-handling rules before implementation starts, and settles which legacy modes are worth keeping.