Interrupted UBI Volume Updates: Recognize the Update Marker Before Blaming UBIFS

A UBI volume with an unfinished whole-volume update can be deliberately unavailable before UBIFS gets a chance to interpret its contents. Check the per-volume update marker and the updater’s completion evidence first. The marker identifies an incomplete replacement state; it does not provide an automatic rollback copy of the previous image.

This guide targets the upstream Linux v6.12 UBI implementation. It distinguishes whole-volume updates from ordinary filesystem writes and atomic single-logical-eraseblock changes. Vendor tools and kernels need their own version checks. The procedure collects diagnostic evidence without initiating a replacement or modifying a marker.

1. Understand the update’s destructive boundary

The UBI userspace interface starts a volume update with a declared byte count, followed by that amount of data through the volume character device. Successful transport of an image to a staging directory is separate from successful completion of this storage operation.

The v6.12 update implementation sets a persistent volume-table marker before replacing content and unmaps the volume’s previous logical eraseblocks. Completion includes writing the declared data, flushing relevant work, and clearing the marker. Interruption can leave the marker set, and ordinary access is then restricted. This is interruption detection, not preservation of the old image.

Do not start a new update as a harmless diagnostic experiment. It changes the target volume. Even a zero-length update is not a read-only probe: the implementation treats it as a wipe. Any replacement must be a separately authorized recovery action with the original evidence and valuable data preserved where possible.

2. Distinguish persistent marker from live updater state

The live updating state describes an operation in progress in the running kernel. The persistent upd_marker can remain after the updater exits or the device restarts. A process disappearing is therefore not evidence that a replacement completed.

In the v6.12 character-device read path, an active update can yield -EBUSY, while a set update marker yields -EBADF. Closing an unfinished update emits a damaged-volume warning and releases its transient buffer. These are specific interface paths, not a promise that every filesystem mount exposes the same error code.

Observed state	Interpretation	Next evidence
Updater still active.	Replacement may still be underway.	Process progress, declared size, write results and final status.
No active updater; marker remains set.	A whole-volume replacement was not recorded as complete.	First failure, interruption time, intended image identity and target identity.
Marker clear; filesystem still fails.	The incomplete-update marker is not sufficient to explain this failure.	Image format, geometry, integrity, lower-layer errors and filesystem evidence.
Marker status unavailable or identity ambiguous.	Classification remains unresolved.	Correct device mapping and an authorized evidence-acquisition plan.

3. Collect a bounded diagnostic record

1. Identify the exact UBI device and volume, its name and type, its MTD parent, and the application or boot slot that uses it.
2. Save kernel build and update-tool versions. Record whether the failing path is a volume read, a UBIFS mount, or an application file access.
3. Capture the volume’s update-marker status and relevant kernel messages without changing its state.
4. Retain the updater’s expected image length and identity, bytes accepted by its write loop, return codes, and final completion result.
5. Order power loss, process exit, storage errors and restart events on a clear timeline.

The volume attribute implementation exposes upd_marker separately from corrupted. Keep them as separate fields in the report. A generic dashboard label such as “bad volume” hides which mechanism produced the classification.

A byte counter reaching its expected total is useful but insufficient alone. The final update path can fail during later work. Retain the actual final result and subsequent verified state rather than reconstructing success from a progress bar or a closed file descriptor.

4. Avoid filesystem repairs at the wrong layer

If the update marker explains the rejection, do not immediately blame a UBIFS superblock or run a format workflow. The lower layer is refusing normal use of an image whose replacement did not complete. Changing filesystem settings does not supply the missing update bytes.

Likewise, do not manually clear the marker to make partial contents look complete. Marker removal is part of the supported update-completion path, not a general integrity repair. A plausible filesystem signature in the first blocks cannot establish that the entire intended image is present.

If the marker is clear, continue diagnosis instead of declaring the volume healthy. An image can have the wrong layout, wrong product identity, unsupported filesystem format, or application-level defects despite having passed through a completed volume update. Storage completion and release acceptance remain different checks.

5. Build an interruption fixture with explicit ownership

Use a disposable UBI volume or a suitable emulated environment. Exclude production calibration, device identity, credentials and unrelated partitions. Preserve a known starting image and use a synthetic replacement whose exact bytes and length are available to the test harness.

Test boundary	Record after the controlled interruption
After update start but before payload delivery.	Marker, normal-access result, updater result and recoverability policy.
During payload delivery.	Delivered prefix, last successful operation and retained marker state.
Near declared-length completion.	Final write result, completion error if any, marker after restart and content verification.
Successful complete replacement.	Clear marker plus independent expected-image and application checks.
Updater exits early without power loss.	Close warning and persistent incomplete-update classification.

These are proposed tests, not executed kernel or hardware results. Do not claim every interruption produces an identical intermediate image. The oracle is that an incomplete or unverified replacement is never reported as a fully accepted release.

Hypothetical diagnostic decision

A service update reaches 70 percent before a power interruption. After restart, a UBIFS mount fails and the volume’s update marker remains set. The initial diagnosis is an interrupted whole-volume replacement, not unexplained filesystem corruption.

The team preserves the update record and confirms the target identity. Any authorized reinstallation uses a verified complete image and a qualified recovery path; it does not assume the former content is still available. The final report separates volume-update completion, filesystem usability and application readiness, making each acceptance claim independently checkable.