12.1 Mount File Systems at Boot by UUID or Label

12.1 Mount File Systems at Boot by UUID or Label

Quick Answer: Identify a file system with blkid, put UUID=... or LABEL=... in /etc/fstab, create the mountpoint, then prove it with mount -a and findmnt. Do not rely on /dev/sdb1 alone—device letters can change. On EX200, graders care that the mount survives reboot.

Official skill and why it matters

Under Configure local storage, Red Hat expects you to configure systems to mount file systems at boot by universally unique ID (UUID) or label. That skill sits next to creating partitions and LVs: once storage exists and has a file system, you must attach it persistently so applications and users still see the data after reboot.

Typical lab wording:

• “Mount the XFS file system on the new partition at /data using its UUID; ensure it mounts at boot.”
• “Label the volume APPDATA and mount it by label at /opt/appdata.”
• “Configure persistent mount for the LV; use UUID in fstab.”

A successful mount /dev/... /mnt in your shell is not enough if /etc/fstab is missing or wrong. Persistence is the objective.

Why UUID and label beat raw device names

If /dev/sdb becomes /dev/sdc after hardware change, an fstab line using /dev/sdb1 fails or mounts the wrong disk. UUID and LABEL follow the file system, which is what you care about.

LVM note: Paths like /dev/mapper/vg-lv or /dev/vg/lv are more stable than sdX, but EX200 wording often still wants UUID (or label) in fstab. When the task says “by UUID or label,” obey that literally.

Discover identifiers: blkid and friends

blkid
blkid /dev/sdb1
blkid -s UUID -o value /dev/sdb1
blkid -s LABEL -o value /dev/sdb1
lsblk -f
lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS
findmnt
findmnt /data

blkid prints TYPE, UUID, LABEL, PARTUUID (partition table UUID—different from FS UUID). For fstab file-system mounts you want the file system UUID from blkid on the partition, LV, or whole-disk FS device—not PARTUUID unless a task specifically uses PARTUUID= (rare on RHCSA; stick to UUID= for FS).

# Useful filters
blkid -t TYPE=xfs
blkid -t LABEL=APPDATA

lsblk -f is excellent under time pressure: one table for FSTYPE, LABEL, UUID, and current mountpoints.

findmnt shows the live mount table in a tree (or JSON/list). Prefer it over scraping /proc/mounts by hand during verification.

Set or change a label

Labels are optional but convenient when the task requires LABEL= in fstab.

ext2/ext3/ext4

e2label /dev/sdb1
e2label /dev/sdb1 APPDATA
# or
tune2fs -L APPDATA /dev/sdb1
blkid /dev/sdb1

XFS

xfs_admin -L APPDATA /dev/sdb1
# clear a label if needed:
xfs_admin -L -- /dev/sdb1
blkid /dev/sdb1

Rules of thumb:

• Keep labels short, unique, and without spaces (use underscores if needed).
• For XFS, the device is often best unmounted when changing the label with xfs_admin (follow what the man page and error messages require on the exam host).
• After labeling, always re-check with blkid before writing fstab.

You can also set a label at mkfs time (mkfs.xfs -L, mkfs.ext4 -L) when you create the FS in a related objective—same end state: LABEL appears in blkid.

/etc/fstab anatomy

Each non-comment line has six fields:

# <file system>  <mount point>  <type>  <options>  <dump>  <pass>
UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890  /data  xfs  defaults  0  0
LABEL=APPDATA  /opt/appdata  ext4  defaults  0  2

Common option tokens

For a normal local data disk on EX200, defaults 0 0 or defaults 0 2 is typical. Root’s pass is 1; extra data volumes often use 0 or 2 depending on policy—match the task if it specifies fsck behavior; otherwise 0 0 is a common safe lab choice for non-root data mounts when you are not told to enable fsck.

Writing UUID and LABEL correctly

# Wrong — missing UUID= prefix, bare hex is not enough in modern fstab style teaching
# a1b2c3d4-...  /data  xfs  defaults  0  0

# Right
UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890  /data  xfs  defaults  0  0
LABEL=APPDATA  /data  xfs  defaults  0  0

No quotes around the UUID in standard fstab. Copy-paste carefully from blkid; a single wrong character fails the mount.

Mountpoint and SELinux awareness

sudo mkdir -p /data
sudo mkdir -p /opt/appdata

The directory must exist before mount or mount -a. Empty mountpoint is fine; if the directory already has files, those files are hidden while the FS is mounted over them—usually unintentional.

SELinux: new data mounts may need context restore or mount options like context= only when a task demands it (covered more under security/file-system chapters). For pure “mount by UUID” objectives, correct fstab + mount is the focus; if services cannot write, check contexts later without abandoning UUID persistence.

Validate without rebooting first

# Syntax/apply all fstab mounts that are not yet mounted
sudo mount -a
echo $?
# 0 is good; non-zero means read the error

findmnt /data
findmnt -s          # fstab view via findmnt (when supported)
findmnt UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890
mount | grep /data
ls /data

mount -a is your primary pre-reboot check. If it errors, fix fstab before reboot—a bad fstab can drop you into emergency mode on real systems. On the exam, still treat mount -a as mandatory verification.

Manual one-shot mount (testing only):

sudo mount UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890 /data
sudo mount LABEL=APPDATA /data
sudo umount /data

After fstab is correct, prefer mount /data (uses fstab) or mount -a.

End-to-end exam workflows

Workflow A — Mount by UUID at /data

Task: Persistently mount the XFS file system on /dev/sdb1 at /data using UUID.

lsblk -f
blkid /dev/sdb1
# UUID="...." TYPE="xfs"
sudo mkdir -p /data
# Edit /etc/fstab (vim/nano) — add:
# UUID=....  /data  xfs  defaults  0  0
sudo mount -a
findmnt /data
# Practice labs: reboot and re-check findmnt /data

Workflow B — Mount by label

Task: Label the ext4 FS BACKUP and mount by label at /backup.

sudo e2label /dev/sdc1 BACKUP
blkid /dev/sdc1
sudo mkdir -p /backup
# LABEL=BACKUP  /backup  ext4  defaults  0  0
sudo mount -a
findmnt /backup

Workflow C — LV with UUID

blkid /dev/mapper/vgdata-lvapp
sudo mkdir -p /srv/app
# UUID=...  /srv/app  xfs  defaults  0  0
sudo mount -a
findmnt /srv/app

Workflow D — Fix a broken fstab line

sudo mount -a
# mount: /data: can't find UUID=...
blkid                    # get the real UUID
sudo vim /etc/fstab      # correct the line
sudo mount -a
findmnt /data

dump and pass (exam hygiene)

• dump field: Keep 0 unless told otherwise; dump is rarely used on RHEL servers.
• pass field: Root FS often 1; other local filesystems 2 if you want ordered fsck; 0 disables fsck at boot for that line. Wrong extra fields (only four columns) break parsing—always six fields.

swap lines (preview for 12.2)

Swap also uses fstab with type swap and mountpoint none (or swap):

UUID=...  none  swap  defaults  0  0

Activation details (mkswap, swapon) are in the next section; the UUID principle is the same.

Common traps

1. Using /dev/sdb1 when the task required UUID/label — works until rename; may lose points if the grader checks fstab content.
2. Typo in UUID — mount -a fails; re-copy from blkid.
3. Missing mountpoint directory — create with mkdir -p.
4. Wrong TYPE — xfs vs ext4 must match blkid TYPE.
5. Duplicate LABEL — two file systems with the same label make LABEL= ambiguous.
6. Forgetting mount -a and only testing a manual mount — reboot then fails.
7. Mounting over a non-empty directory without noticing hidden files.
8. Confusing PARTUUID with UUID — use FS UUID from blkid on the FS device.
9. Spaces or quotes mangling the fstab line.
10. noauto left on when the task expects boot-time mount — remove noauto so auto behavior applies.

Relationship to other storage objectives

Order on the exam is often: create storage → mkfs → fstab UUID → verify.

Section checkpoint

You should run blkid/lsblk -f, set labels with e2label or xfs_admin -L when required, write six-field /etc/fstab lines using UUID= or LABEL=, ensure the mountpoint exists, validate with mount -a and findmnt, and treat reboot survival as the real success criterion. That is the EX200 standard for mounting file systems at boot by UUID or label.