Persistent naming - UUIDs, labels, and stable paths · Linux

A common production failure is a host that does not boot because /etc/fstab referenced /dev/sda1 and a hardware change made the disk /dev/sdb1 after reboot. The fix is to use stable identifiers that survive hardware changes.

Why /dev/sd* is not stable

Device names like /dev/sda are assigned by the kernel in probe order. The first SATA device found is sda; add another disk and it might become sdb. The order depends on:

SATA port numbers in the firmware
USB device insertion order
Hotplug events
BIOS enumeration quirks

Any of these can change between reboots. Using /dev/sd* in /etc/fstab is a recipe for “the host does not boot” after the next hardware change.

The three stable identifiers

Read-only / Safestable identifiers— blkid shows the three stable identifiers per partition. UUID is random at mkfs time, label is human-readable and set at mkfs time, PARTUUID is unique to the partition table entry. Any of these is suitable for fstab.

$ blkid -o device,uuid,label,partuuid /dev/sda1 /dev/sda2

/dev/sda1: 1a2b-3c4d-... system-boot
/dev/sda2: 5e6f-7a8b-...

Identifier	Set by	Stable across	Use for
`/dev/sda1`	Kernel probe order	No	Debugging only
`UUID=...`	Filesystem at mkfs	Reformat, but not hardware	`/etc/fstab` (default)
`LABEL=...`	Filesystem at mkfs	Reformat, not hardware	Removable media
`PARTUUID=...`	Partition table at creation	Repartition, not hardware	Identifying a specific partition
LVM UUID	LVM metadata	Reformat of PV	`fstab` for LVM
`/dev/disk/by-uuid/...`	udev	Hardware changes	Symlink for scripts

The /etc/fstab pattern

Read-only / Safeproduction fstab— Production fstab uses UUID= for every entry. The mount options (defaults, noatime) and dump/pass fields follow. UUID survives hardware changes - a disk moved to a different SATA port is still found by UUID.

$ cat /etc/fstab

UUID=1a2b-3c4d-... /boot ext4 defaults 0 2
UUID=5e6f-7a8b-... / ext4 defaults,noatime 0 1
UUID=9a8b-7c6d-... /var ext4 defaults 0 2
UUID=f1e2-d3c4-... swap swap defaults 0 0

When to use labels instead

Labels are human-readable and useful for:

Removable media that you want to identify by purpose (LABEL=DATA, LABEL=BACKUP).
Multi-OS hosts where the same disk is used in different contexts.
Build artifacts (live USB sticks, rescue disks) where the UUID is unknown at boot time.

Configuration changeset label— e2label sets the label on an ext2/3/4 filesystem. xfs_admin is the equivalent for XFS. Labels are limited to 16 characters and must be unique across the system.

$ e2label /dev/sdc1 BACKUP-2026