A server's /etc/fstab refers to data partitions as /dev/sdb1 and /dev/sdc1. After an extra disk controller is installed, the machine fails to boot correctly. Why does using UUID= instead avoid this class of failure?
LPIC-1 Exam 101-500, objective 104. Devices, Linux filesystems, filesystem hierarchy standard medium
Machine-checked — no person has signed for it. This question was read against the source cited below by an automated pass, which found no contradiction. That is a weaker claim than it sounds: the same kind of process wrote the question, so it can confirm its own mistake.
Treat it as a good draft rather than as settled fact, and read the source below before you rely on it. It is not used in mock exams here — only questions a person has signed for are.
How these questions are written — where each question comes from, what the verification ledger records, and what happens when one is found wrong.
The options
Not correct UUIDs are generated fresh at every boot, so they always match the current device order.
Wrong, and backwards. A UUID is fixed at mkfs time and only changes if you deliberately change it (for ext, tune2fs -U). Its whole value is that it does not change.
Correct A UUID is stored inside the filesystem itself, so it follows the data no matter which /dev/sd* name the kernel assigns during that boot.
Correct. Kernel device names are handed out in detection order, which changes when hardware, drivers or boot timing change. The filesystem UUID is written by mkfs and travels with the filesystem.
Not correct Mounting by UUID skips the filesystem check, so a renamed device cannot stall the boot.
Wrong. The fsck pass field governs checking, and it applies identically whether the entry names a device, a LABEL or a UUID.
Not correct UUIDs are resolved by DNS, so they work even if the local device nodes are missing.
Wrong. Nothing here involves the network. Device UUIDs are resolved locally by udev, which populates /dev/disk/by-uuid/ symlinks.
Why
Persistent naming options in fstab are UUID=, LABEL= and PARTUUID=. Their identifiers live with the filesystem or partition table rather than with the enumeration order, so they survive added disks, changed cabling and different boot timing. `blkid` and `lsblk -f` print them; udev exposes them as symlinks under /dev/disk/.
Where this comes from
- Cited
- LPI exam objective 104.3
- What it says
- Identify filesystems by UUID or label rather than by unstable device names.
Practise this
Reading one question is not practice. The trainer will draw a short set from objective 104 and space the ones you get wrong.
More questions on this objective
- A new disk /dev/sdb has no partition table at all. Which command writes an empty GPT partition table onto it without dropping you into an interactive editor? machine-checked
- You need the partition /dev/sdc1 on a USB stick to carry a FAT32 filesystem so that Windows machines can read and write it. Which command creates it? machine-checked
- You have just run `mkswap /dev/sdb2`. Which command makes the kernel start using that swap area immediately, without a reboot? machine-checked
- Why is it dangerous to run e2fsck against an ext4 filesystem that is currently mounted read-write? machine-checked
- On an ext4 filesystem at /dev/sda1 you want an automatic check to be forced after every 30 mounts. Which command sets that? machine-checked
- `df -h /var` reports the filesystem 100% full, but `du -sh /var` accounts for only about half that space. Nothing is hidden under a mount point. What is the most likely explanation? machine-checked
All questions on Devices, Linux filesystems, filesystem hierarchy standard