Dennis HilkLinux Fix LabDE

Boot, GRUB & systemd-boot

A required fstab mount sends boot into emergency mode

A missing non-root mount can block systemd’s local filesystem target; identify the exact fstab dependency before making optional mounts nonfatal.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • Boot reaches an emergency shell after waiting for a filesystem.
  • A mount or local-fs.target dependency fails after a disk was removed or renamed.

Relevant environment

systemd systems using /etc/fstab. This entry concerns a non-root mount; unavailable root storage needs early-boot diagnosis.

Recognizable messages (synthetic examples)
systemd[1]: Dependency failed for local-fs.target - Local File Systems.

Find the preceding mount/device/fsck failure; this aggregate message does not justify disabling every mount check.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • An fstab UUID, path, type or mount option may no longer match the intended device.
  • A mount treated as required may be optional in reality; a failed filesystem check or device error can also block it and must not be hidden.

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 and validate /etc/fstab without mounting entries. Run from the affected installation, not blindly against a live image’s fstab.

findmnt --verify --verbose

Interpret the result: A missing source or invalid option narrows configuration problems. A clean syntax check does not prove the physical device or filesystem is healthy.

Check 2

List failed mount units in the current systemd instance without retrying them.

systemctl --failed --type=mount --no-pager

Interpret the result: Inspect the unit matching the fstab mount point, then its journal. An empty list in an initramfs or after reboot may not describe the failed host boot.

Evidence-guided next steps

Correct the identified mount definition

If device identity or an option is wrong, back up fstab and update only the affected line to the verified filesystem identity and supported options. Re-run findmnt validation before the next normal boot.

Precautions: Do not edit the root, encryption or recovery entries by guesswork. If the disk has I/O errors, investigate those before forcing a mount.

Recovery / rollback: Restore the backed-up fstab from the emergency or rescue environment if normal boot regresses.

Did this solution help you?

Share this solution#

Make a truly optional mount nonfatal

If the disk is intentionally removable and no essential service depends on it, add the documented nofail policy and an appropriate device timeout for that entry. Configure dependent workloads not to write into an empty mountpoint.

Precautions: Do not use nofail to conceal failure of /, /usr or required application data. The system may boot while the optional data remains unavailable.

Recovery / rollback: Restore the prior mount options and dependency policy if the volume must become required again.

Did this solution help you?

Share this solution#

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.