Symptoms & scope
- Boot stops in maintenance after a filesystem checker reports uncorrected errors.
- Root remains unavailable or read-only while normal services cannot start.
Relevant environment
Distributions checking a writable root filesystem at boot through systemd-fsck or initramfs helpers. Filesystem-specific tools and policies differ.
Recognizable messages (synthetic examples)
systemd-fsck[250]: /dev/mapper/root: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.Identify its type and mount state before filesystem-specific offline recovery; this does not justify bypassing checks.
systemd-fsck[250]: fsck failed with exit status 4.Read the preceding checker detail and physical I/O context; exit status 8 is an operational error and intentionally excluded from this specific interpretation.
Possible causes
These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.
- Metadata inconsistency after interrupted writes may require repair beyond automatic policy.
- Wrong device/type, missing checker or physical I/O errors can also fail the check; repair must target the actual root layer, not its encrypted container.
Diagnose safely
Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.
Check 1
Read the checker’s device, messages and exit status from the affected boot; journal access may need an administrator.
journalctl -b --no-pager --grep='systemd-fsck|UNEXPECTED INCONSISTENCY|fsck failed'Interpret the result: Status bits distinguish corrected errors, reboot-needed and uncorrected errors. A missing-checker failure needs package recovery, not immediate filesystem rewriting.
Check 2
Read the root mount’s source, type and options. In rescue, this describes rescue root unless the installed root has been separately identified.
findmnt -no SOURCE,FSTYPE,OPTIONS /Interpret the result: Resolve device-mapper or subvolume layers before repair. An installed root already mounted writable must not be checked with an offline repair tool.
Evidence-guided next steps
Use filesystem-specific offline recovery
If uncorrected filesystem errors are confirmed, save recoverable data or an image first and use supported rescue media with the target filesystem unmounted. Follow that filesystem’s documented check/repair procedure for the identified root volume.
Precautions: Do not run a generic fsck -y against an encrypted container or use another filesystem’s repair tool. Address underlying I/O failure before repeated metadata rewrites.
Recovery / rollback: Filesystem repair may alter data irreversibly; recover from the pre-repair image/backup if needed rather than promise an undo command.
Did this solution help you?
Repair a missing checker or incorrect mount policy
If the failure is a missing filesystem utility or incorrect fstab type/options, restore the appropriate distribution utility and correct the verified root definition. Rebuild early images only if their check path depends on it.
Precautions: Do not set fsck.mode=skip or remove pass numbers to conceal genuine uncorrected errors. Preserve the original definition before editing.
Recovery / rollback: Restore the saved fstab/initramfs configuration and use the prior supported image if boot regresses.
Did this solution help you?
References & review
This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.
- systemd boot filesystem checker behavior (project or distribution documentation)
- util-linux fsck status and filesystem-specific dispatch (project or distribution documentation)