U-Boot UBI Selection: A Failed Switch Does Not Preserve the Previous Attachment

A recovery script selects a second UBI partition, sees an error and
then tries to continue using the first one. In U-Boot v2025.01, that
fallback assumption is unsafe: switching to a different partition
detaches the existing UBI device before the new target is resolved or
attached. With UBIFS command support, an existing UBIFS mount is also
removed.

This article examines U-Boot’s selection lifecycle, including its use
in Buildroot-based products. It does not diagnose UBI image geometry,
prescribe repartitioning or explain interrupted volume-update markers.
Those problems occur at different boundaries.

Distinguish
a current attachment from a requested name

The ubi part command without a partition argument
reports the currently selected device and its backing MTD partition.
With a partition name, it calls ubi_part(), optionally
passing a VID-header offset. These are different operations: one
observes current state, while the other can dismantle that state. Tagged
UBI command implementation.

The selection function first checks whether the current attachment’s
MTD name matches the requested name. If so, it returns success
immediately. That shortcut does not rescan the device or compare a newly
supplied VID-header-offset argument. A second successful selection of
the same name is therefore not evidence that altered attachment
parameters were exercised.

For a different name, the next operation is
ubi_detach(). Only afterward does U-Boot probe MTD devices
and look up the requested name. If the name does not exist, the function
returns failure after the old selection has already been cleared. If the
name exists but the new UBI scan fails, there is likewise no restoration
of the previous attachment in this function.

Detachment also
changes filesystem state

When CONFIG_CMD_UBIFS is enabled,
ubi_detach() checks whether UBIFS is mounted and invokes
its unmount helper before exiting the UBI subsystem. It then sets the
selected UBI pointer to null. This prevents subsequent filesystem
commands from continuing with stale mount state after changing the
underlying device. UBI
detachment.

The UBIFS unmount helper clears its mounted and initialized flags.
Both the listing and loading commands check the mounted flag before
accessing files, and reject an unmounted state. Re-selecting the
original UBI partition alone does not recreate that UBIFS mount; the
mount step must succeed again. UBIFS
command state.

This gives a concrete explanation for a recovery trace that ends with
“not mounted” after an earlier partition-selection failure. The
filesystem warning may be a consequence of the deliberate detach, rather
than evidence that the first partition’s data changed. Diagnose the
state transition before proposing filesystem repair.

Reconstruct fallback
explicitly

Model a recovery attempt as a sequence of states: attached partition,
optional mounted volume, new selection attempt, and resulting attachment
state. On a failed switch, enter a known unattached state in the
script’s logic rather than carrying forward a cached “partition A is
ready” flag.

If the product’s approved fallback is to use partition A, explicitly
select A again and check that result. Then mount the intended UBIFS
volume and check that result before issuing a file load. A raw UBI
volume read and a UBIFS file load are different consumers; only the
latter requires the filesystem mount described here.

The proposed qualification should include a valid alternate
partition, a nonexistent MTD name and an alternate partition that cannot
attach. Observe current selection and mount availability after each
attempt. Separately compare a repeated same-name selection with a real
detach-and-reattach sequence when investigating changed attachment
parameters. Use recoverable test media; no selection, mount or flash
operation was executed for this article.

The key contract is the transition, not the spelling of the target: a
failed switch does not preserve the old attachment, and success from the
same-name shortcut does not prove a new scan occurred.