Control Boot-Time File-System Checks with systemd-fsck
You will be able to explain why a file-system check ran at boot, inspect the result without running a checker against a mounted device, and choose a deliberate boot-time policy when recovery requires it. Allow about 10 minutes for inspection. Changing the policy or repairing a file system may require a maintenance window and an unmounted device.
The route
Jump straight to the step you need, or tick off Done means at the end.
1. Check the installed behaviour
This guide follows systemd 255, installed here as 255.4-1ubuntu8.17. The service is not a general-purpose file-system checker. It selects the checker for the file-system type, such as fsck.ext4, and starts it for a device whose mount configuration requests checking.
Check the version and the unit definitions first:
systemctl --version | head -1
systemctl cat [email protected]
systemctl cat systemd-fsck-root.serviceExpected output begins with a systemd version and shows a oneshot service whose executable is /usr/lib/systemd/systemd-fsck. The instance unit is used for ordinary file systems and for the root file system in the initrd. The root and /usr units cover those mounts only when the initrd has not already checked them.
Checkpoint
You have confirmed which systemd release you are troubleshooting and whether the check belongs to the initrd or the running system.
2. Find the setting that caused the check
For a normal boot, systemd-fsck considers an /etc/fstab entry only when its final passno field is greater than zero and the file system is configured to mount at boot. An entry with noauto does not meet that condition. The root file system is checked before other file systems; unrelated checks may run in parallel, except checks on the same rotating disk.
Inspect the entries without editing them:
findmnt --fstab --evaluate
awk '!/^[[:space:]]*#/ && NF >= 6 { print $1, $2, $3, "passno=" $6 }' /etc/fstabIn the second command, a result such as UUID=... / ext4 passno=1 means the entry requests a check. A final field of 0 does not. Do not infer the device from a comment: use the actual source field or ask findmnt.
Check the current boot's units and messages:
systemctl list-units --all 'systemd-fsck*'
sudo journalctl -b -u 'systemd-fsck*' --no-pagerThe first command may show no active instances if the checks finished and were unloaded, or if none were needed. The journal is the useful record of the checker that was selected and its exit result.
Checkpoint
You have matched the boot result to an /etc/fstab entry and captured the relevant journal messages.
3. Understand repair and failure boundaries
The default repair mode is preen. That lets the file-system checker repair problems it considers safe, while leaving decisions that need an explicit answer. This is not a guarantee that every fault is harmless, so keep a backup and plan for a console or out-of-band connection before forcing a repair.
For the root and /usr services, a checker result meaning that the system should reboot activates reboot.target. A result meaning that errors remain uncorrected activates emergency.target. An ordinary instantiated [email protected] fails for either result. If its file system is in /etc/fstab without nofail or noauto, the local file-system target can then enter emergency mode.
Safety boundary
Never run a repair checker against a mounted writable file system merely to test it. If the journal says repair is needed, arrange a boot into a suitable recovery environment or unmount a non-root file system first. Stopping a unit does not make a mounted device safe to repair.
4. Use the kernel command line for one controlled boot
When the machine cannot complete boot, systemd-fsck reads two kernel command-line settings. They are useful for one recovery boot, but they affect the whole boot and should not be left in a boot-loader entry by accident.
| Setting | Values | Effect |
|---|---|---|
fsck.mode= | auto, force, skip | Use the checker's normal decision, always request a full check, or skip checks. |
fsck.repair= | preen, yes, no | Use safe automatic repair, answer yes to checker questions, or answer no. |
auto and preen are the defaults. fsck.mode=force can make boot slow and can expose faults that normal checking would defer. fsck.mode=skip is a diagnostic escape hatch, not a repair. It may let a damaged file system mount and should be removed immediately after the recovery boot.
At the boot-loader menu, edit the temporary kernel line, append only the setting you need, boot once, and record the result:
cat /proc/cmdline
sudo journalctl -b -u 'systemd-fsck*' --no-pagerWarning
fsck.repair=yes answers yes to every question from the checker. Use it only when you understand the checker and have accepted the risk of automatic changes. If you changed a persistent boot-loader configuration instead of editing one boot entry, undo that change before the next reboot.
5. Avoid the common troubleshooting traps
- Do not expect
systemctl start systemd-fsck@...to be a safe manual test. The unit is tied to a device and is designed for boot ordering. - Do not treat a clean journal message as proof that every file system was checked. A checker can decide that no check is needed, and
passno=0ornoautoprevents the boot-time request. - Do not confuse
nofailwith skipping the check. It changes how a mount failure affects boot; it does not by itself turn off checking. - Do not assume the aliases are separate implementations.
systemd-fsck(8),systemd-fsck-root.service(8), andsystemd-fsck-usr.service(8)document the same file-system check logic as the instantiated service.
After a recovery boot, return to the ordinary policy, remove temporary kernel settings, and verify the next boot's journal rather than relying on memory.
Done means
- You identified the relevant
/etc/fstabentry, including itspassnoand mount-at-boot settings. - You checked the current boot's systemd-fsck journal as a privileged user.
- You know whether the root,
/usr, or an instantiated service owns the result. - Any forced, skipped, or yes-to-all policy was temporary, recorded, and removed after recovery.