Why does fstab use UUID instead of the actual file system name?

filesystems mount disk-usage fstab

49,164

Solution 1

The advantage of using the UUID is that it is independent from the actual device number the operating system gives your hard disk.

Imagine you add another hard disk to the system, and for some reason the OS decides that your old disk is now sdb instead of sda.

Your boot process would be screwed up if fstab points to the device name. But in case of the UUIDs, it is fine.

More detailed information about UUIDs can also be found on the blog post "UUIDs and Linux: Everything you ever need to know"

Solution 2

In that case, can I modify /etc/fstab to this?

You can and it will probably be okay, but most likely it would be better to leave the UUID.

UUIDs are arbitrary strings used to identify, in this case, a partition on a block device; its stored with the partition itself, and can be assigned a different one if desired (sort of like MAC addresses).

The advantage of using the UUID is that it is unmistakable, whereas /dev/vda is not; it could happen that it ends up being a different drive at boot time, although this may be totally theoretical in context (e.g., because you only have one drive of a particular type).

Another more subtle example of where using the device name can cause a problem would be the recent switch on some systems to using consistent network device names. If this occurred as an upgrade and you used a hardcoded device name in a network script somewhere, it would break. A parallel example WRT block devices might be a kernel or udev upgrade which changes the naming scheme.

One point of UUIDs is to make these kind of things possible and painless. So while you can use the device name, there is no advantage to doing so unless (e.g.) you have a system where you swap different drives in. In other words, if you don't have a good reason to do that, stick with the UUID.

Solution 3

You can do man fstab for a fairly concise read on the contents and semantics of the /etc/fstab file. On my x86, fairly up-to-date Arch linux server, man fstab gives me this:

The second field ... describes  the mount point for the filesystem.

So, yes, /dev/vda apparently is one of many names for some device, as is UUID=050e1e34-39e6-4072-a03e-ae0bf90ba13a, given that both names appear to mount on "/".

If you look in the directory /dev/disk/by-uuid/ you can see symbolic links that point to things like /dev/sda1, /dev/sdb1 on my server. This might be another way to check your hypothesis. /dev/disk has subdirectories by-id, by-path, by-uuid which all appear to be alternate names for the same device.

49,164

its_me

Updated on September 18, 2022

Comments

its_me over 1 year
For example, this is the first line of my /etc/fstab:
```
UUID=050e1e34-39e6-4072-a03e-ae0bf90ba13a    /    ext4    errors=remount-ro    0    1
```
And here's the output of df -h command (reporting free disk space):
```
honey@bunny:~$ df -T

Filesystem     Type     1K-blocks    Used Available Use% Mounted on
/dev/vda       ext4      30832636 4884200  24359188  17% /
none           tmpfs            4       0         4   0% /sys/fs/cgroup
udev           devtmpfs    498172      12    498160   1% /dev
tmpfs          tmpfs       101796     320    101476   1% /run
none           tmpfs         5120       0      5120   0% /run/lock
none           tmpfs       508972       0    508972   0% /run/shm
none           tmpfs       102400       0    102400   0% /run/user
```
1. From the two is it okay to deduce that UUID=050e1e34-39e6-4072-a03e-ae0bf90ba13a represents /dev/vda given that the first column in fstab is <file system>?
2. So, would it be okay if I modified /etc/fstab to this?
```
/dev/vda    /    ext4    errors=remount-ro    0    1
```
3. EDIT: If yes (to above question), why does the sudo blkid command show a different UUID for /dev/vda?
```
$ sudo blkid

/dev/vda: LABEL="DOROOT" UUID="6f469437-4935-44c5-8ac6-53eb54a9af26" TYPE="ext4"
```
  What am I missing here?
  
  Answer: I'd conclude (3) to be a bug in the cloud of my host. So yes, the UUID reported by blkid (or ls -l /dev/disk/by-uuid) should be the same as the one used in /etc/fstab.
- Avinash Raj almost 10 years
  
  Check the UUID with sudo blkid command.
- its_me almost 10 years
  
  @AvinashRaj Hmm, weirdly, the sudo blkid command outputs a different UUID for /dev/vda. This adds to my confusion. :) (Updated question.)
- Joe almost 10 years
  
  It is not a good sign that the blkid command shows a different UUID - please check the current UUID with `ls -l /dev/disk/by-uuid''. Since its vda, might it be that the underlying VM infrastructure changed something?
- its_me almost 10 years
  
  @liquidat This is the output I got: lrwxrwxrwx 1 root root 9 Jun 18 11:04 6f469437-4935-44c5-8ac6-53eb54a9af26 -> ../../vda. As for your other question, I'll contact the web host about that.
- Joe almost 10 years
  
  I'd say that the machine might not reboot since the fstab entry is plain wrong. Could be a cloned disk or something. I take it that there is no other device which has the UUID given in fstab?
- Florian Heigl over 8 years
  
  as for the uuid, the only relevant thing is tune2fs -l I think. the uuid used for the root device upon reboot is probably set in the grub config.
its_me almost 10 years

In that case, the problem (as updated in my question) is that I get two different UUIDs for /dev/vda! Please see the question one more time.
its_me almost 10 years

Okay. So what explains the different UUIDs for /dev/vda in /etc/fstab and reported by blkid? (Please see the updated question if you haven't.)
goldilocks almost 10 years

Rather than asking in an update, you should ask that as a separate question ("Why is my mounted partition UUID different than the one in fstab?").
Admin almost 10 years

If I answered the original question, it might be a good idea to mark it "answered" and write a new question, just so you don't collect irrelevant answers, answers that work with the original and not the modified question.
Tommy about 8 years

yep. even without adding a new disk, your kernel may decide to just swap two of your drives' dev mounts one day. See wiki.archlinux.org/index.php/Persistent_block_device_naming
aloplop85 over 7 years

what happens if I want to clone the image to another disk, which have a different UUID?
boot13 almost 5 years

There's at least one situation where UUIDs are less useful: if you clone an entire disk, then reboot, you may get partitions mounting from either disk, or the wrong disk.
Joe almost 5 years

That's true - check the linked blog post, it even has a section when not to use them.
steveayre over 4 years

If you clone the disk you should change the UUID on the new disk. tune2fs xfs_admin or reiserfstune can do that depending on your filesystem.