How to find and change the UUID of a drive in Linux

When strange problems start appearing in Linux, such as booting issues, endless waiting times, or disks that previously mounted without problems now failing to appear, the culprit is often the same: a UUID changed or misconfiguredKnowing how to locate, understand, and modify these identifiers is almost a rite of passage for anyone managing a GNU/Linux system with multiple disks or partitions.

In this article we will look at it in great detail How to check the UUID of your drives, how to change it securely And which system files you should check to ensure everything continues to boot properly. You'll see. commands , the blkid, ls -l /dev/disk/by-uuid, uuidgen, tune2fshow they relate to /etc/fstabWhat happens to the swap partition and what to consider if you clone a complete system with tools like Clonezilla.

What is a UUID and why is it used in Linux?

The term UUID (Universally Unique IDentifier) It refers to a universally unique 128-bit (16-byte) identifier. In its most common format, it is displayed as a string of 32 hexadecimal digits divided into five groups separated by hyphens, following the pattern 8-4-4-4-12, which gives a total of 36 characters including hyphens. A typical example would be something like this: 123e4567-e89b-12d3-a456-426614174000.

In GNU/Linux systems, this identifier is associated with each device storage or partition (ext4, XFS, swap partitions, etc.) and serves to refer to them independently of the classic device name (/dev/sda1, /dev/nvme0n1p2etc.), which can change if you connect or disconnect disks. In this way, the system can always mount the same partitions although the order in which the disks are detected may vary.

Not all partitions have exactly the same UUID format: for example, in partitions with format NTFS it is usual to find 16 hexadecimal digits without hyphens (64 bits), while in partitions FAT32 the identifier can have 8 hexadecimal digitsEven so, for practical purposes in Linux they are still treated as unique identifiers for each volume.

One of the most important uses of these codes is the file /etc/fstab, where they are defined mounting points and mounting options of each partition. There you will usually see a column with entries of the type UUID=xxxx-xxxx... instead of /dev/sdXprecisely to gain stability and avoid surprises when you change the hardware.

Methods to view the UUID of your disks in Linux

Before touching anything, it's advisable to know precisely which partitions you have and their associated UUIDs. Linux offers several tools, such as parted and also to check the UUIDs of all disks connected, both by command line and through graphical utilities.

Query UUID with the blkid command

One of the most direct ways to view identifiers is by using BLKIThis command requires administrator privileges, so you will need to run it with sudo or as a user rootIf you launch it without parameters, list You can use all detected devices:

sudo blkid

La output It usually displays lines like this:

/dev/sda1: UUID="8aa6c0d2-c18e-4606-b1da-f5f1f7617f00" TYPE="xfs" PARTUUID="..."

Each line associates a device /dev with its UUID, the type of file system (ext4, xfs, vfatetc.) and other metadata such as PARTUUIDIf you are only interested in filtering by a specific device, you can specify it as a parameter:

sudo blkid /dev/sda1

If you want to locate the UUID of the partition you're interested in without having to check all the lines, you can use... grepFor example, to see the identifier of /dev/sdd4:

sudo blkid | grep sdd4

This same UUID It's the one you'll see later in /etc/fstab if that partition is configured to mount automatically on the BootSo it's important to be very clear about this. which line corresponds to each assembly point.

Use the /dev/disk/by-uuid directory to view links

Another very practical option to see what UUID each partition has is to list the contents of the directory. /dev/disk/by-uuid/In that directory, the system creates symbolic links where each filename is the UUID of a device, and the link points to the actual device in /dev/.

To see the entire list simply run:

sudo ls -l /dev/disk/by-uuid/

The exit will show you Something like:

lrwxrwxrwx 1 root root 10 ... 8aa6c0d2-c18e-4606-b1da-f5f1f7617f00 -> ../../sda1

This way you can see at a glance what UUID corresponds to each /dev device and cross-reference that information with what appears in /etc/fstab or with what other tools show, such as lsblk o gpartedIt is especially useful when you are debugging assembly problems or correcting errors in configuration files.

View UUIDs and mount points with lsblk

The command lsblk It is a very convenient tool for viewing, in tree form, the relationship between disks, partitions, logical volumes and their mount pointsAlthough its primary purpose is not to display UUIDs, you can combine it with some options to get a fairly complete view of the storage system.

A typical invocation would be:

lsblk -o NAME,MOUNTPOINT,TYPE

In the column MOUNTPOINT You'll see routes like /, /home, /boot, /mnt/datosetc. From there you can find out which device do you want to inspect and then use blkid or review /dev/disk/by-uuid to see its identifier. This is especially useful when the system mounts drives in unfriendly paths (for example, some NAS devices or tools like OpenMediaVault that mount in /srv/ with long names like dev-disk-by-uuid-XXXX).

Query UUID via /etc/fstab

Another way to quickly see which UUIDs are being used on your system is to check the file /etc/fstab, Which defines which partitions are mounted and where during startup. You can check it with:

cat /etc/fstab

In it you will find lines similar to:

UUID=8aa6c0d2-c18e-4606-b1da-f5f1f7617f00 /backups xfs rw,noquota,nofail 0 1

The first column uses the UUID as the partition identifier, followed by mount point’s most emblematic landmarks, the filesystem type (in this example, xfs) and the mounting options (rw,noquota,nofailetc.). Check /etc/fstab It's a good habit to occasionally check, especially after changing disks, repartitioning, or reinstalling systems, to make sure that the UUIDs still match the real ones.

Furthermore, a simple:

cat /etc/fstab | grep UUID

will allow you to locate Quickly find all entries identified by UUID, which is very useful when you suspect that an identifier has become outdated and is causing boot problems.

Typical UUID problems: slow boot times and shared swap

One of the most frequent symptoms of a misconfigured UUID is that The system hangs during startup. For quite some time, usually around a minute and a half, it displays messages indicating that it cannot find a particular partition. After this waiting period, the boot process continues, but the problematic partition is not mounted.

This usually happens when in /etc/fstab There is an entry with a UUID that no longer existsPerhaps it's because you've changed a disk, formatted a partition, or reinstalled another distribution on the same disk, which has generated a new identifier. The system tries to mount that partition with a UUID that no one has and waits until it expires. There.

A fairly common case occurs when you have a dual system (for example, Ubuntu and Debian) sharing the same partition linux-swapImagine a disk with three partitions: sdc1 like swap, and sdc2 y sdc3 as root partitions in ext4 for Ubuntu and Debian, respectively. If you first install Ubuntu in sdc3 and then Debian in sdc2It is common for the Debian installer to reformat the swap and change its UUID.

The result is that the first installed system (Ubuntu, in this example) has in its /etc/fstab un Old UUID for swapWhen it boots, it looks for that partition with an identifier that no longer exists, waits the maximum time, considers it lost, and continues booting without mounting swap. It's not the end of the world, but it's a source of slowness and unnecessary RAM consumption.

To diagnose cases like this, you can use graphical tools such as GPartedIf you don't have it installed, on Debian-based distributions you can do it with:

sudo apt install gparted

Once you launch GParted, select the disk and right-click on the swap partition to choose the option to insightsThere you will see information such as the device name (sdc1), the type ( )linux-swap) And the current UUIDThat is the identifier that must also appear in the /etc/fstab of each system that uses that swap.

The solution involves editing the /etc/fstab of the system that has an outdated UUID (for example, Ubuntu) and replace the old UUID with the new one that you've seen in GParted or with blkidYou can do it with your favorite editor, for example:

sudo nano /etc/fstab

After saving the changes, on the next boot the system will find the correct swap partition and the boot process will be smooth again. This same procedure applies to any other partition whose UUID has changed due to a reinstall, formatting, or poorly executed cloning.

Generate and change UUIDs in Linux

There comes a time when reading UUIDs is not enough: you need generate new identifiers or change existing onesThis may be necessary when cloning disks, when wanting to avoid conflicts between systems, or simply for organizational purposes. Linux offers several tools for these tasks, some general (uuidgen) and others specific to certain file systems (tune2fs for ext2/3/4).

Generate new UUIDs with uuidgen

Utility uuitgen It is responsible for creating and displaying new UUIDs, using the library libuuidThe generated identifiers are, in practice, unique both in the local system and in any other system, past, present or future, since they follow standards designed to avoid collisions in a statistically very improbable way.

There are mainly two generation modes that it handles uuidgen: time-based UUIDs y random UUIDsThe first ones use the system clock and address MAC of the network card (if available), while the latter rely on a random number generator high quality, usually /dev/random o /dev/urandom.

In some distributions, such as Debian 9 Stretch, the tool uuidgen It is not installed by default. In that case, you can add it by installing the package. uuid-runtime:

sudo apt update
sudo apt install uuid-runtime

Once installed, its general syntax is very simple:

uuidgen

The most common options are:

• -r, –random: generates a UUID based on randomnessusing the system's random number generator.
• -t, –time: generates a UUID based on the time and MAC address of the machine.
• -h, --help: displays help and exits.
• -V, –version: displays the version and exits.

If you run uuidgen Without parameters, you will directly obtain a new UUID in your terminal which you can copy and use wherever you need it, for example in scripts or custom configuration files.

Change the UUID of an ext2/3/4 partition with tune2fs

If what you want is for an existing partition to have a new UUIDIn ext2, ext3, or ext4 file systems, the reference tool is tune2fsThis command allows you to modify internal parameters of the file system, including its identifier.

Before changing anything, it is essential unmount the partition to avoid data corruption. Let's say you want to modify the UUID of /dev/sdd4The basic flow would be:

sudo umount /dev/sdd4

Once disassembled, you can ask tune2fs that generates a new random UUID directly:

sudo tune2fs /dev/sdd4 -U random

If you prefer to control the specific identifier yourself (for example, to use one generated earlier with uuidgen), you can also pass the value explicitly:

sudo tune2fs /dev/sdd4 -U 123e4567-e89b-12d3-a456-426614174000

After the change, it's a good idea to check the result with blkid or reviewing /dev/disk/by-uuid To confirm that the identifier has been updated:

sudo blkid /dev/sdd4

Remember that if that partition appears in /etc/fstab or other configuration files, you will need to Manually update the new UUID to prevent the system from continuing to search for the old identifier upon startup.

Edit /etc/fstab to use UUIDs in mounts

The recommended way to define persistent mounts in Linux is to use UUID in /etc/fstabThe general syntax for a UUID-based entry is something like this:

UUID={TU-UUID} /ruta/de/montaje tipo_fs opciones 0 1

For example, for an XFS disk intended for backups, you might have a line like this:

UUID=8aa6c0d2-c18e-4606-b1da-f5f1f7617f00 /backups xfs rw,noquota,nofail 0 1

In this example, the option nofail This makes the system not consider it critical if the disk is not present at startup, which is very useful for external drives or backup disks that are not always connected. Other options include noquota o errors=remount-ro They depend on the type of file system and the use you are going to give it.

Once you have modified /etc/fstab To add or update any entry, it is recommended to test the configuration without restarting, using:

sudo mount -a

If there are no errors, you will be able to see the result with:

df -h | grep backups

or similar, replacing backups by the mount point that corresponds to your case. If something goes wrong, check that the UUID is correct and that the indicated file system matches the actual one.

System cloning and UUID conflicts

One scenario that raises many questions is the cloning of entire systems, for example with tools such as ClonezillaWhen cloning one disk to another, the data is copied just like the partitions, their file systems and their UUIDsThis means that for a while you will have two different disks with partitions that share the same identifier.

This overlap might not be a problem if you only boot from the clone or the original alternately, but if you connect both at the same time on the same machine, it's likely that errors will appear. UUID conflictsThe system won't know exactly which partition each identifier corresponds to, and you may experience mounting errors, confusing boot times, or even have partitions from the clone mounted where you expected those from the original disk.

To avoid these conflicts, it is common practice to proceed change the UUIDs of the clone partitions After cloning, ensure each disk is clearly differentiated. For ext4 partitions, you can rely, as we saw earlier, on uuidgen to generate new identifiers and in tune2fs to apply them.

If your system has a somewhat more complex structure, for example a root in ext4 > LVM > LUKS (dm-crypt), you should be aware that there may be UUID at various levelsThese include: file system files, LVM physical volume files, logical volume files, LUKS container files, etc. Additionally, files such as /etc/crypttab They can reference those identifiers.

In a typical case with encryption, the scheme might look something like this:

nvme0n1 (disco físico)
├─nvme0n1p1 /boot/efi
├─nvme0n1p2 /boot
└─nvme0n1p3 (partición cifrada LUKS)
└─nvme0n1p3_crypt
├─sys--vg-root /
└─sys--vg-swap_1

If you change UUIDs at any point in this chain, you must ensure that you update all places where they are referenced: /etc/fstab for mount points, /etc/crypttab for encrypted volumes and, in some cases, boot parameters that GRUB uses to locate the root.

Regarding GRUB, in many modern configurations it itself menu entry uses UUID To find out where the root partition is located. That is, something like this appears in the kernel line: root=UUID=...When you regenerate the file grub.cfg running update-grub (or the equivalent command in your distribution), the system rereads the disks and updates those identifiers. Therefore, after modifying UUIDs on a bootable clone, it's highly recommended to boot from that clone and perform a GRUB configuration regeneration to ensure everything is consistent.

In practice, the reasonable workflow when cloning a complete system and wanting to use it in parallel with the original is usually:

• Boot from the clone (to avoid confusion with device names).
• Change the UUIDs of the partitions you want to differentiate (with tune2fs or the tools that correspond to each file system).
• Update / etc / fstab and, if applicable, /etc/crypttab with the new identifiers.
• Regenerate GRUB configuration (for example with sudo update-grub in Debian/Ubuntu).

Although it may seem a bit laborious, this approach ensures that the clone will be fully bootable and independent of the original, and that both can coexist on the same machine without stepping on each other.

Mastering UUID management in Linux allows you to diagnose slow boot times, troubleshoot problems with changed partitions, and configure more robust mounts. /etc/fstabSharing swap space between distributions without problems and cloning entire systems while keeping everything under control. In the end, it's just a matter of correctly identifying which partition belongs to which, and checking their code with tools like blkid o ls -l /dev/disk/by-uuidand make it a habit to review and update key configuration files whenever you make significant changes to your disks.