fstab by UUID + Emergency Recovery

blkid - a hands-on Linux lab on a real virtual machine.

Mount filesystems persistently by UUID in /etc/fstab and recover a machine a bad line dropped into emergency mode. Read the UUID with blkid (or lsblk -f), write the six-field line by UUID, then the RHEL 10 ritual: systemctl daemon-reload so the systemd-fstab-generator re-reads the file, mount -a and findmnt --verify to prove the line is safe BEFORE rebooting. When a bad line strands the boot, log in at emergency mode, mount -o remount,rw / to fix fstab, and reboot. Serves EX200 local-storage: configure systems to mount file systems at boot by UUID.

You spent twenty minutes building it. A logical volume, formatted XFS, mounted at /mnt/web, a sentinel file inside to prove it works. You move on to the next task. Later the machine reboots, you come back, and /mnt/web is empty. The filesystem still exists on disk, but nothing mounted it. Every task that depended on that mount just scored zero.

A live mount command only lasts until the next reboot. To make a mount survive, you write it into one file: /etc/fstab. On the exam this is the difference between points that stick and points that evaporate overnight. But there is a trap: a single typo in that file can drop the whole machine into emergency mode at the next boot. This lesson teaches you to mount by UUID persistently AND to recover when a bad line strands the machine.

The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs are from a real RHEL 10 machine (AlmaLinux 10.2) with two spare disks and a real LVM stack. The UUIDs are shown as <varies> because every filesystem gets its own, so yours will read differently. What stays true everywhere is the SHAPE: the six fstab fields, the blkid form, and the RHEL 10 daemon-reload rule.

/etc/fstab is the filesystem table. At every boot, systemd reads it and mounts everything listed, in order. Each line has six fields, separated by spaces: the device to mount, where to mount it, the filesystem type, the mount options, a dump flag, and a boot-check pass number.

The first field, the device, is where engineers get burned. You could write /dev/vdb1, but device names move. Add a disk and vdb can become vdc; the line now points at the wrong disk, or nothing. A UUID is a unique ID baked into the filesystem itself when you format it, and it never changes no matter how the disks are ordered. The exam expects UUID-based entries for exactly this reason. Reference filesystems by UUID, never by device name.

/etc/fstab has existed for decades and the six-field format has barely changed. What changed on modern RHEL is who reads it. Instead of one mount pass at boot, systemd runs a systemd-fstab-generator that turns each fstab line into a mount unit it manages. That indirection is powerful, but it has one consequence you must remember: when you edit fstab, systemd does not notice until you tell it to re-read the file.

That re-read is systemctl daemon-reload, and on RHEL 10 it is required after editing fstab. Older habits skipped it because a bare mount -a often worked anyway. On RHEL 10, run systemctl daemon-reload first so the generator rebuilds the mount units from your new line, then mount -a. We drill this exact order below.

Before you can write a UUID into fstab, you have to read it off the filesystem. The tool is blkid. Point it at a device and it prints that device's UUID and filesystem type. Hand it your new XFS logical volume and the swap partition together to see both at once.

Before you run it, decide what you expect: an XFS volume should report TYPE="xfs", and a formatted swap partition should report TYPE="swap". Read them:

blkid /dev/vgdata/lvweb /dev/vdc1

prompt: [root@servera ~]# answer: blkid /dev/vgdata/lvweb /dev/vdc1 output: /dev/vgdata/lvweb: UUID="<varies>" BLOCK_SIZE="512" TYPE="xfs" /dev/vdc1: UUID="<varies>" TYPE="swap" PARTLABEL="primary" PARTUUID="<varies>" hint: The tool is blkid followed by the device paths: blkid /dev/vgdata/lvweb /dev/vdc1

Two lines, one per device. The XFS volume reports TYPE="xfs"; the swap partition reports TYPE="swap". The value you copy into fstab is the UUID="..." field. Note that swap also shows a PARTUUID, which is the partition's ID, not the filesystem's; for an fstab mount you want the plain UUID. The move is always this: blkid the device, copy its UUID, then build the fstab line around it.

The literal UUID strings are <varies> here on purpose. Every filesystem is formatted with its own unique UUID, so the exact characters on your machine will differ from any capture. What is stable is the FORM: blkid <device> returns that device's UUID= and TYPE=, whatever the characters happen to be today. On the machine, copy the real value; never type one from a lesson.

Now build the persistent mount. An fstab line for the XFS volume mounted at /mnt/web reads left to right: the UUID= you copied from blkid, then the mount point /mnt/web, then the type xfs, then defaults for the options, then 0 for dump, then 0 for the boot-check pass. Six fields.

You append that line to /etc/fstab with an editor or a redirect. The shape you are aiming for is exactly this (your UUID replaces the placeholder):

UUID=<the-uuid> /mnt/web xfs defaults 0 0

prompt: [root@servera ~]# answer: echo "UUID=<the-uuid> /mnt/web xfs defaults 0 0" >> /etc/fstab output: hint: Echo the six-field line and append it with >> to /etc/fstab: echo "UUID=<the-uuid> /mnt/web xfs defaults 0 0" >> /etc/fstab

The line is now in /etc/fstab, but writing it is not the same as it working. systemd has not re-read the file yet, and you have not proven the line mounts. Two things stand between you and a safe reboot: tell systemd to re-read the file, then test the mount. Never reboot on an untested fstab line. That is the exact mistake that empties /mnt/web and strands the machine.

The six fields are separated by whitespace, not commas. A common exam slip is writing the type as ext4 when the volume is really xfs (or the reverse). If the fstab type does not match the real filesystem, the mount fails at boot. Confirm the type with blkid and copy it exactly: xfs for XFS, ext4 for ext4, swap for swap.

Here is the RHEL 10 safety ritual, and it is not optional. First, systemctl daemon-reload makes the systemd-fstab-generator rebuild its mount units from your edited file. Second, mount -a reads /etc/fstab and mounts everything not already mounted. If mount -a prints nothing, every line is good. If it prints an error, you fix it NOW, while you still have a running system, not after a reboot has locked you out.

Run the reload, then the test:

systemctl daemon-reload

prompt: [root@servera ~]# answer: systemctl daemon-reload output: hint: The systemd re-read command is systemctl daemon-reload, no arguments: systemctl daemon-reload

No output, which is success: systemd rebuilt its mount units from the new fstab. Now the generator knows about /mnt/web. The next command actually mounts it and, more importantly, tells you whether the line is safe to boot on. On RHEL 10 do these two in this order every time you touch fstab: daemon-reload, then mount -a.

mount -a mounts things, but there is a stronger check that reads the whole fstab and validates every line without mounting anything: findmnt --verify. It catches missing mount points, unknown filesystem types, and malformed lines, and it reports a clean bill of health when the file is sound. This is the command that gives you confidence to reboot.

Run the verifier over your fstab:

findmnt --verify

prompt: [root@servera ~]# answer: findmnt --verify output: Success, no errors or warnings detected hint: The verifier is findmnt with the --verify flag: findmnt --verify

Success, no errors or warnings detected. Every line in /etc/fstab is syntactically sound and every mount point and type checks out. That message is your green light: the machine will boot cleanly on this fstab. If instead findmnt --verify had printed a warning about an unknown target or a bad type, you would fix that line before going anywhere near a reboot.

Suppose the worst happens anyway: a bad fstab line slips through and the machine reboots. systemd cannot mount the line, the boot stalls, and you land at a prompt that reads Welcome to emergency mode! and asks for the root password for maintenance. This is not a dead machine. It is a rescue shell, and the fix is a fixed routine.

Log in with the root password. The root filesystem may be mounted read-only, so you cannot save an edit yet. Remount it read-write, edit the offending line, then reboot. The remount is the step people forget:

mount -o remount,rw /

prompt: [root@servera ~]# answer: mount -o remount,rw / output: hint: Remount the root filesystem with the rw option: mount -o remount,rw /

Root is now writable. From here you open /etc/fstab, and you either fix the broken field or comment the whole line out with a # at the front so it is skipped. Then you re-verify with findmnt --verify, and reboot with systemctl reboot. The offending mount is gone or corrected, and the machine boots normally. The lesson under the lesson: this whole recovery only exists because someone rebooted on an untested fstab. Run mount -a first and you never meet emergency mode.

Scaffolding off. No command is printed this time. You have every piece you need.

You have just added a mount line to /etc/fstab and you want the strongest possible confirmation, before you dare reboot, that every line in the file is valid: correct fields, real mount points, known filesystem types. You do not want to actually mount anything, just validate. Which single command reads the whole fstab and reports whether it is sound?

prompt: [root@servera ~]# answer: findmnt --verify output: Success, no errors or warnings detected hint: It is findmnt with a flag that checks rather than mounts. The flag is --verify.

findmnt --verify reads /etc/fstab and validates every entry without mounting a thing, then prints Success, no errors or warnings detected when the file is clean. That is the one command that earns you the right to reboot: it turns a nervous guess into a checked fact. Pair it with mount -a and you have both proofs, the line mounts AND the file is sound, before the machine ever restarts.

You earned this cheat sheet. Every row is a form you just ran or built:

The one thing to burn in for the exam: after editing /etc/fstab on RHEL 10, always systemctl daemon-reload then mount -a (or findmnt --verify) BEFORE you reboot. A tested line costs ten seconds; an untested line costs you emergency mode and every task that depended on the mount.

Reference filesystems by UUID, never by /dev/vdb1, because device names can shift when disks are added or reordered while a UUID is fixed to the filesystem. If a mount is non-critical and you would rather the machine boot even when it fails, add nofail to the options field: it keeps a missing device from dropping you into emergency mode.

The practice terminal has shown you the full persistence loop: blkid to read a UUID, the six-field fstab line built around it, systemctl daemon-reload so RHEL 10 re-reads the file, mount -a and findmnt --verify to prove the line is safe, and the emergency-mode routine that rescues a machine a bad line stranded. Every one of those you typed yourself.

The local-storage module mission is where you run these against a real RHEL 10 machine with spare disks. A full VM boots for you, with its own real disks, its own UUIDs, and its own fstab waiting to be written. The mission hands you objectives that use exactly what you practiced here: read a UUID, mount a filesystem persistently by that UUID, and prove the fstab is sound before you reboot. One difference from this lesson: the mission shows no commands. You read the objective, recall the blkid and the fstab shape and the daemon-reload then mount -a ritual, and type it. That recall is what makes it stick on exam day.

Finish the other local-storage lessons, then go make a real machine's mounts outlive a reboot.

Practice fstab by UUID + Emergency Recovery in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.