sysadmin · June 5, 2026 · 14 min read

fstab, done safely.
UUID mounts, ext4, and recovering a broken boot.

The database volume has to survive reboots, mounted by UUID. Plus a legacy ext4 volume, and the recovery drill for the broken fstab that took a box down last week.

// what we’re getting into
  1. The ticket
  2. Concept review. The fstab fields.
  3. Persist /srv/db by UUID
  4. Test without rebooting
  5. Add the legacy ext4 volume
  6. The broken fstab recovery drill
  7. Exam questions
  8. Final checklist: confirm everything works

The ticket: dbadmin1 has two needs and a scar. First, /srv/db must mount automatically on boot using its UUID, not the device path, and it has to be tested without a reboot. Second, a second logical volume needs to be ext4 for a legacy app, mounted at /srv/legacy. And they want to learn the recovery flow, because a typo in fstab took a staging box down last week and needed remote hands.

The real problem: a bad fstab line can stop a machine from booting. The whole point of this ticket is persisting mounts safely and knowing how to recover when it goes wrong.

What we are doing: UUID-based fstab entries, an ext4 volume alongside the XFS one, and the broken-fstab recovery drill.

The ticket

bash
lsblk
sudo lvs               # confirm dbvg/dblv from the LVM ticket
sudo blkid /dev/dbvg/dblv

Concept review. The fstab fields.

bash
man fstab
man mount
man mkfs.xfs mkfs.ext4

Each fstab line has six fields: the device, the mountpoint, the filesystem type, the mount options, a dump flag that is always 0, and a pass number that controls fsck order (0 for none, 1 for root, 2 for everything else).

fstab fields
device         mountpoint   fstype   options    dump  pass
UUID=xxxx      /srv/db      xfs      defaults   0     0

Always use the UUID, not the device path. Device names like /dev/sdb are assigned by the kernel at boot and can shift when you add hardware. The UUID lives inside the filesystem itself and never moves.

Persist /srv/db by UUID

Back up fstab before every edit. Then capture the UUID into a variable and append a clean line.

bash
sudo cp /etc/fstab /etc/fstab.bak.$(date +%Y%m%d)

DB_UUID=$(sudo blkid -s UUID -o value /dev/dbvg/dblv)
echo "UUID=$DB_UUID /srv/db xfs defaults 0 0" | sudo tee -a /etc/fstab
tail -1 /etc/fstab

Test without rebooting

This is the reboot test you can run safely. Unmount what is there, then let fstab mount everything. If mount -a works cleanly, the reboot will too.

bash
sudo umount /srv/db
mount | grep /srv/db    # should be empty now

sudo mount -a
mount | grep /srv/db    # mounted again, from fstab this time
df -h /srv/db

Add the legacy ext4 volume

Same pattern, different filesystem. Create the volume, format ext4, and persist it by UUID.

bash
sudo lvcreate -L 500M -n legacylv dbvg
sudo mkfs.ext4 /dev/dbvg/legacylv
sudo mkdir -p /srv/legacy

LEGACY_UUID=$(sudo blkid -s UUID -o value /dev/dbvg/legacylv)
echo "UUID=$LEGACY_UUID /srv/legacy ext4 defaults 0 0" | sudo tee -a /etc/fstab
sudo mount -a
df -hT /srv/legacy    # -T shows the filesystem type

The broken fstab recovery drill

Practice this now, calmly, so you can do it under pressure later. Add a deliberately bad line, watch mount -a reject it, then recover from the backup. That same error at boot is what drops a machine into emergency mode.

bash
sudo cp /etc/fstab /etc/fstab.working

# add a bad line on purpose
echo "UUID=0000-bad /broken xfs defaults 0 0" | sudo tee -a /etc/fstab
sudo mount -a    # error: cannot find the UUID. this is what blocks boot

# recover: restore the good file and re-test
sudo cp /etc/fstab.working /etc/fstab
sudo mount -a    # clean again
sudo rm /etc/fstab.working
warning: If a bad line does reach a reboot and the box lands in emergency mode, the recovery is: log in as root, remount root read-write with mount -o remount,rw /, fix or remove the bad line in /etc/fstab, then systemctl reboot. Knowing this is the difference between a two minute fix and a call to the data center.

Exam questions

Write the command first.

Q1. Find and display the UUID of /dev/dbvg/dblv.

Q2. Create a persistent fstab entry for the XFS volume /dev/dbvg/dblv at /srv/db using its UUID, and test it without rebooting.

Q3. A malformed fstab entry makes mount -a fail. Walk through fixing it on a running system, then explain recovery if the box already rebooted into emergency mode.

Answers.

bash
# A1
sudo blkid /dev/dbvg/dblv
# A2
UUID=$(sudo blkid -s UUID -o value /dev/dbvg/dblv)
echo "UUID=$UUID /srv/db xfs defaults 0 0" | sudo tee -a /etc/fstab
sudo umount /srv/db 2>/dev/null; sudo mount -a; df -h /srv/db
# A3
# running system: fix the bad line, then mount -a to verify
# emergency mode: mount -o remount,rw / ; fix /etc/fstab ; systemctl reboot

Final checklist: confirm everything works

If every check passes, the ticket is done.

bash
# 1. /srv/db mounts by UUID, verified with mount -a
grep /srv/db /etc/fstab; df -h /srv/db

# 2. /srv/legacy is ext4 and mounts by UUID
df -hT /srv/legacy

# 3. fstab backed up before edits
ls /etc/fstab.bak.*

# 4. broken-fstab recovery drilled at least once
# 5. all three exam commands written from scratch
# 6. tracker entry checked off

Reply to dbadmin1: /srv/db (XFS) and /srv/legacy (ext4) both persist by UUID and pass mount -a. For a broken fstab: boot to emergency mode, remount root read-write, fix the file, reboot.

next post
Emergency swap when the database is getting OOM-killed