UBIFS Becomes Read-Only: Distinguish a Filesystem Error Latch from a Read-Only UBI Device

When UBIFS stops accepting writes, establish which layer became read-only and capture the first causal error. A read-only filesystem mount, a UBIFS error latch, and a read-only UBI device are related observations, but they are not interchangeable diagnoses. Repeated later EROFS results often describe the consequence rather than the initiating fault.

This diagnostic method is pinned to Linux v6.12. Vendor kernels can change the paths and messages, so compare the deployed source before interpreting internal flags. The outcome is an evidence-based fault classification, not a command sequence that forces a damaged volume writable.

1. Keep four states separate

The UBIFS error-transition helper sets ro_error, enables data-CRC checking, marks the superblock read-only, and emits a warning on the first transition. Several UBIFS I/O wrappers then reject subsequent operations with -EROFS. Their original failed operation can instead return the error that caused the transition.

At initialization, ro_media is set for a corrupted UBI volume, a read-only UBI device, or a static UBI volume. ro_mount tracks the filesystem’s read-only mount state. These distinctions appear in the v6.12 mount and remount implementation. They are internal implementation fields, not four independent user-facing controls.

State or observation	Meaning to investigate	What it does not prove
Mount was intentionally read-only.	Boot configuration or an authorized operating mode requested it.	A flash fault occurred.
UBIFS error transition, ro_error.	The filesystem latched a fault and stopped normal writes.	The entire underlying UBI device also switched state.
UBIFS initialized with ro_media.	Volume/device properties prevented ordinary writable use.	The media wore out during this boot.
UBI device reports ro_mode.	The lower storage layer is read-only.	The particular filesystem was the initiating layer.

2. Identify the object before collecting symptoms

Map the failing application path to its current mount, UBI volume number, UBI device number, and MTD parent. Capture the mount namespace used by that service. A host shell can inspect a different mount from a container or isolated service, and a pathname alone does not identify the storage object.

Record kernel build identity, filesystem type, volume type, partition map, boot arguments, and the time of each observation. Keep the association between a log line and its device identifiers. Two volumes on one UBI device can produce nearby messages without having identical filesystem histories.

UBI exposes a read-only ro_mode device attribute in the v6.12 device implementation. A value observed after the incident is a state sample, not a timestamped explanation of how it arose. Preserve earlier boot and fault messages alongside it.

3. Find the first transition, not the loudest retry

Build a short ordered timeline: last known successful product operation, earliest storage-related error, UBIFS transition warning if present, mount/device state samples, and later application failures. Use a clock domain that allows ordering; wall-clock adjustments can otherwise reverse apparent cause and effect.

Include messages preceding the UBIFS warning. Capture the original operation, error code, logical eraseblock or offset when reported, and relevant lower-layer messages. A log full of repeated read-only failures is less useful than the first I/O failure that preceded them.

If logging was lost, report the cause as unresolved. Do not infer that the first surviving message was the first actual failure. Add bounded capture for the next controlled reproduction rather than repeatedly stressing valuable media to obtain a cleaner trace.

4. Use the layer comparison to choose the next investigation

• UBIFS transition with UBI still writable: investigate the originating filesystem operation and its lower-level result. This combination is possible; it does not invalidate the filesystem’s protection.
• UBI already read-only at attachment: inspect the attachment reason and MTD configuration before diagnosing a runtime filesystem fault.
• Intentional read-only mount with no fault transition: verify deployment policy and the application’s expected storage destination.
• Both layers read-only after an error: order the events. The final pair of states alone cannot identify which transition happened first.
• Inconsistent observations: check device identity, namespaces, timestamps, and missing logs before choosing a repair.

For example, UBI initialization can select read-only operation when the MTD device is not writable or when its header arrangement shares a minimal I/O unit. Those checks are visible in the attachment geometry code. Neither condition is, by itself, an endurance measurement.

5. Preserve evidence before attempting recovery

Stop optional write attempts and retain a bounded fault indication outside the failing store where the product design permits it. Preserve authorized copies of valuable data and diagnostic evidence before any operation that changes storage state. Avoid rebooting merely to clear the visible symptom; it can remove the timeline needed for diagnosis.

A remount request is not a repair. The v6.12 remount path has explicit rejection checks for prior UBIFS errors and read-only media in its read-only-to-writable transition. Other branches and earlier synchronization can fail too. Review the actual path rather than treating one error message as a universal recovery recipe.

Any later recovery plan needs separate approval of the affected data, exact target, and permitted loss. This article provides no erase, format, detach, or forced-remount commands. Read-only protection should not be bypassed simply because the application needs to save a setting.

6. Qualify the diagnostic path on disposable storage

Create a controlled fixture with no production data. Record a clean writable baseline, an intentionally read-only mount, and a simulated filesystem I/O failure using an appropriate test harness. If testing a lower-layer read-only transition, isolate it as a separate case and document the injection point. Do not manufacture these faults on a live device.

For every case, check the identity mapping, first error, transition order, observed mount state, UBI state, and application classification. Confirm that later retries do not replace the stored first-cause record. These are proposed tests; no kernel fault-injection or hardware execution is claimed here.

Hypothetical classification

A gateway’s settings service reports read-only failures. Its UBI device still reports writable, while an earlier UBIFS warning follows a failed logical write. The evidence supports a filesystem error-latch investigation, not an assertion that UBI is read-only or that the flash has exhausted its life.

Release the diagnostic feature with the layer-state table, object mapping, first-error timeline, and disposable transition fixtures. A useful diagnosis explains why writes stopped without silently converting protection into permission to modify the media.