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.

  • 1
    Check the UUID with sudo blkid command. Jun 18, 2014 at 15:56
  • @AvinashRaj Hmm, weirdly, the sudo blkid command outputs a different UUID for /dev/vda. This adds to my confusion. :) (Updated question.)
    – its_me
    Jun 18, 2014 at 16:02
  • 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?
    – liquidat
    Jun 18, 2014 at 16:20
  • @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.
    – its_me
    Jun 18, 2014 at 16:22
  • 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?
    – liquidat
    Jun 18, 2014 at 16:28

3 Answers 3


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"

  • 1
    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
    – Tommy
    Apr 13, 2016 at 16:22
  • what happens if I want to clone the image to another disk, which have a different UUID?
    – aloplop85
    Sep 21, 2016 at 9:21
  • 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.
    – boot13
    Jun 5, 2019 at 21:13
  • That's true - check the linked blog post, it even has a section when not to use them.
    – liquidat
    Jun 11, 2019 at 18:05
  • 2
    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.
    – steveayre
    Dec 11, 2019 at 10:48

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.

  • 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.)
    – its_me
    Jun 18, 2014 at 16:12
  • 6
    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?").
    – goldilocks
    Jun 18, 2014 at 16:17

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.

  • 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
    Jun 18, 2014 at 16:06
  • 1
    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.
    – user732
    Jun 18, 2014 at 16:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .