Dennis HilkLinux Fix LabDE

Storage & Filesystems

A filesystem UUID in fstab no longer matches

Resolve a missing data mount after cloning or reformatting by comparing fstab identifiers with actual filesystem UUIDs and verifying device identity.

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 waits for a device UUID that is not currently present.
  • A data mount disappears after replacing or recreating a filesystem.

Relevant environment

Systems using /etc/fstab and UUID-based local mounts, including systemd-generated mount units.

Recognizable messages (synthetic examples)
systemd[1]: Timed out waiting for device /dev/disk/by-uuid/11111111-2222-3333-4444-555555555555.

Check both fstab identity and device detection; the timeout is not proof the UUID itself is incorrect.

Possible causes

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

  • Reformatting creates a new filesystem UUID, while fstab may still refer to the old one.
  • A disconnected or undetected drive can make a correct UUID unavailable; identical cloned UUIDs can be ambiguous.

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 available device identities and filesystem UUIDs; some fields may require elevated read access on your distribution.

lsblk -o NAME,PATH,MODEL,SERIAL,FSTYPE,UUID,MOUNTPOINTS

Interpret the result: Match model, serial, partition and filesystem rather than replacing UUIDs based on /dev/sdX alone. A missing device needs detection checks first.

Check 2

Read and verify /etc/fstab without mounting it; administrator read access may be needed for some source probes.

findmnt --verify --verbose

Interpret the result: An unresolved UUID supports a stale reference or missing device. Successful verification checks syntax and availability, not whether the mount contains the intended data.

Evidence-guided next steps

Correct the verified fstab source

If the intended filesystem is positively identified and has a different UUID, back up fstab and update only that mount’s source field. Verify the file again and test the single non-root mount during a local maintenance window.

Precautions: Do not replace every UUID or alter root/boot entries by analogy. Ensure the mountpoint is not being used for new writes while the intended disk is absent.

Recovery / rollback: Restore the saved fstab if the mount is wrong. Keep local recovery access before rebooting a machine with boot-critical changes.

Did this solution help you?

Share this solution#

Set optional-drive policy deliberately

If the UUID is correct but the drive is deliberately removable, configure only that mount as optional using documented nofail or automount behavior. Fix undetected permanently required storage rather than hiding its absence.

Precautions: An optional mount can let boot continue while applications write into the bare mountpoint. Gate services on the actual mount where their data requires it.

Recovery / rollback: Restore the original mount options and dependent-service configuration from the recorded backup if behavior is unsuitable.

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.