Linux Mint – Understanding how Universally Unique Identifiers work

How to Change the server name on Windows Server 2019

The last section of this chapter deals with another aspect of storage in Linux that some may find confusing. This is Universally Unique Identifiers ( UUIDs). You’ve no doubt seen Linux names storage devices using virtual device files such as /dev/sda, /dev/sdb, and so on. In the preceding sections, you had seen this everywhere, even in the /etc/fstab file when listing the partitions that are mounted each time you start your system, created during installation. However, there was a bit of a problem with this type of system that UUID tried to solve.

In today’s day and age, we remove and insert media constantly. A typical desk drawer may contain a plethora of flash drivers, and in the typical desktop PC, we may have multiple hard disks and may add additional storage devices later. Each time we add media to the computer, it is assigned a virtual device file by the kernel. Typically, the first partition on the first hard drive used by Linux will be /dev/sda1, the second on the same drive will be /dev/sda2, and the first partition of the second hard drive will be /dev/sdb1, and so on.

This can be a major problem when swapping storage devices. If the storage device /dev/sda (which will likely contain your boot loader) is seen by Linux to be a different disk or if you add storage devices and the virtual devices change order, your system may not boot or the disks may not be located in the filesystem where you expect them to be. To solve this dilemma, UUIDs are used by virtually all Linux distributions today to ensure that disks and their partitions are assigned in the proper order and to the appropriate places in the filesystem.

You may have noticed several UUIDs displayed in the fstab screenshot earlier in this chapter. The lines began with UUID=. The UUID values are generated based on several factors of the disk and are expected to be unique to that disk. Having two disks or partitions that generate the same UUID is immensely unlikely. Thus, when the system looks for specific UUIDs when mounting disks and partitions, it’s extremely unlikely that the system will ever be confused about which partition should be mounted where. Therefore, you can reorder your disks and not expect to suffer issues while booting, at least as far as the Linux kernel is concerned. Think of UUIDs as generating a unique serial number for each of your storage devices.

However, the UUID system is not without its own set of flaws. If a partition is resized, the UUID would change and would need to be adjusted manually. The same would occur if you wanted to upgrade your hard drive to a larger one. If you cloned your current disk to a new larger disk, the UUID of the target disk would be different, and Linux would be confused during the boot process. If you manually cloned a disk, you would need to manually update GRUB (the bootloader) as well as the /etc/fstab to reflect the new UUID values. To see the current UUIDs for your disk and partitions, execute the following command:


ls -l /dev/disk/by-uuid

You may recall that when modifying the fstab file , we used the following line:


/dev/sdb1  /mnt/mydisk  rw,relatime,data=ordered 0 0

Instead, we could have (and possibly should have) used a UUID to direct the fstab file to the partition we wished to mount. The preceding line could be changed to the following after generating a UUID:


UUID=b679d5bc-736a-46be-8e6b-b3d40e6e4caa   /mnt/mydisk  rw,relatime,data=ordered 0 0

Now that we have converted our fstab entry to use a UUID, we can be certain that the disk will always be mounted where we designated it. If we ever resize or replace this volume, all we’d need to do is determine the new UUID and replace it in our fstab file, and we would be good to go.

Comments are closed.