What is so special about UUIDs in Linux? I don’t know! But here is everything you ever need to know about UUIDs on Linux.
A single, simple short tip about looking up UUIDs in Linux from 2007 is one of the most successful posts I ever wrote. And is still looked up by hundreds each day! So I decided: Feed the masses.
This list covers everything about Linux and UUIDs. And it is feature complete. Of course. *cough*
Background
UUIDs are 128 bit long numbers represented by 32 hexadecimal digits and which are used in software development to uniquely identify information with no further context. They are described in RFC 4122, an example UUID is:
13152fae-d25a-4d78-b318-74397eb08184
UUIDs are probably best known in Linux as identifier for block devices. The Windows world knows UUIDs in the form of Microsoft’s globally unique identifiers, GUID, which are used in Microsoft’s Component Object Model.
The UUIDs are generated in various variants: originally most of them were derived from the Computer’s MAC, later hash sums of names were used. And about the question, how many UUIDs there are and how big the chance is that you will generate a a number you already own, here are some numbers from Wikipedia’s UUID article:
After generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%. The probability of one duplicate would be about 50% if every person on earth owns 600 million UUIDs.
Usage in fstab
As mentioned UUIDs are most often used in Linux to identify block devices. Imagine, you have a couple of hard disks attached via USBs, than there is no persistent, reliable naming of the devices: sometimes the first USB hard disk is named “sda”, sometimes it is named “sdb”. So to uniquely address the right disk for example in your /etc/fstab, you have to add an entry like:
UUID=9043278a-1817-4ff5-8145-c79d8e24ea79 /boot ext3 defaults 0 2
For the block device itself, the uuid is stored in the superblock.
Beware however that UUIDs should not be used in fstab when you work with LVM snapshots. See the section “When not to use them” below for more details.
Linux implementation and generation
In Linux UUIDs are generated in /drivers/char/random.c?id=refs/tags/v3.8, and you can generate new ones via proc:
$ cat /proc/sys/kernel/random/uuid eaf3a162-d770-4ec9-a819-ec96d429ea9f
There is also the library libuuid which is used by uuidgen and especially by the ext2/3/4 tools E2fsprogs to generate UUIDs:
$ uuidgen f81cc383-aa75-4714-aa8a-3ce39e8ad33c
How to get them, bash style
The most interesting part in UUIDs is most likely how to get the current UUIDs of the hard disks. As already mentioned years ago, there are two major ways to retrieve them: a simple ls call in a special directory, and the tool blkid.
So, first the ls call which has to be made in the directory /dev/disk/by-uuid. The directory contains links named after the UUIDs and pointing to the “real” block device files. Pretty handy if you are on a system where hardly anything is installed.
$ ls -l /dev/disk/by-uuid lrwxrwxrwx 1 root root 10 11. Okt 18:02 53cdad3b-4b01-4a6c-a099-be1cdf1acf6d -> ../../sda2
The second call uses the tool blkid which is part of the util-linux package. It provides a real interface to actually query for certain devices and also supports searching for labels.
$ blkid /dev/sda1 /dev/sda1: LABEL="/" UUID="ee7cf0a0-1922-401b-a1ae-6ec9261484c0" SEC_TYPE="ext2" TYPE="ext3"
And there are even more ways! Let’s install hwinfo:
$ hwinfo --block [...] UDI: /org/freedesktop/Hal/devices/volume_uuid_3e953ee0_79f2_4d94_98b3_5f49ad652b7c [...] Device Files: [...] /dev/disk/by-uuid/3e953ee0-79f2-4d94-98b3-5f49ad652b7c [...]
As you see hwinfo lists huge amounts of data about your hardware – among them are the UUIDs of the devices. Use it when you are grabbing for more data about the block devices anyway.
Or how about udevadm? It is the udev provided tool for querying data from the udev database. This database contains all the information udev has about the system, so the UUID info is just one among many, many other data. If you are writing a “modern” script which integrates with Linux standard tools nicely, I guess I would go with udev. But for pure, quick and dirty command line utilization, it produces a bit too many information, just like hwinfo.
$ udevadm info -q all -n /dev/sda1|grep uuid S: disk/by-uuid/9043278a-1817-4ff5-8145-c79d8e24ea79 E: [...] /dev/disk/by-uuid/9043278a-1817-4ff5-8145-c79d8e24ea79 E: ID_FS_UUID=9043278a-1817-4ff5-8145-c79d8e24ea79 E: ID_FS_UUID_ENC=9043278a-1817-4ff5-8145-c79d8e24ea79
In this context the tool udevinfo is also mentioned sometimes. However, that is deprecated, most distributions don’t ship it anymore. Also, another often mentioned way to retrieve the UUIDs is the program /lib/vol/vol_id. But as described in bug redhat#476379 vol_id is only a private udev function. It should not be used by outside programs (or people) since the application interface is not stable. Also, the entire program might be removed in the future and in fact is already removed on some distributions.
Another tool which contains many disk data is dumpe2fs. It prints the super block and blocks group information for the selected filesystem and thus has also knowledge about the uuid:
$ sudo dumpe2fs /dev/dm-0|grep UUID dumpe2fs 1.44.2 (14-May-2018) Filesystem UUID: 11aef60d-3d80-49d8-aa7b-bf3510d946cb
And not to forget is lsblk which can has a nice structured output in the shell, providing not only the UUID but also the directory, available storage and so on. The advantage of this command is that it is very easy to identify which disk carries which UUID:
$ lsblk -f NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT nvme0n1 │ ├─nvme0n1p1 │ vfat 6972-1366 633,8M 3% /boot/efi ├─nvme0n1p2 │ ext4 5b62c867-016d-492d-b8a0-e50baf353952 715,1M 20% /boot ├─nvme0n1p3 │ crypto f1859e2a-acfa-49a8-b9e4-bf3d9dec4208 │ └─luks-f1859e2a-acfa-49a8-b9e4-bf3d9dec4208 │ ext4 4e385121-f4b0-4d91-86fe-26119c25c8b4 141,2G 14% /home
Thanks to __ :~) __bernard for the tip.
How to get them, GUI style
If you are afraid of shells, there is of course a KDE-GUI tool available as well to look up the UUID: /usr/bin/kcmshell4 devinfo
Setting a UUID
As mentioned in the comment section, it can be also interesting to set a UUID. Since the UUID is part of the superblock the way to set it depends on the used file system. For ext file systems you can use tune2fs:
# tune2fs -U new_uuid /dev/sdaX
When not to use them
As mentioned by Zhenech it is not always advisable to use UUIDs everywhere.
Since it is not possible to mount two file systems with the same UUID with most file systems, extra care need to be taken when LVM snapshots (or cloned disks) are used in an environment: mounting might fail due to duplicate UUIDs.
XFS: Filesystem dm-2 has duplicate UUID - can't mount
One way to deal with this is by the way to change the UUID during creation or afterwards, another way is to mount with the nouuid option.
Note that Btrfs is different here, since you might mount multiple sub-volumes, all of them from a different main UUID, as Ben pointed out.
Anything else
If you have any other, further information, please post them in the comments! I will happily add them here. After all, my years old short tip already got me 250 k visits, I wonder how many a comprehensive list will bring me…
/home/liquidat 
I want translate this post,Can I do it? Excuse me for my poor english.
Yes, you can translate it, as mentioned in the licence cc-by-sa (also shown on the left side). So: you are free to translate the post, but need to put it under the same licence, and you have to link back to the original. =)
Nice info. Maybe you could do an article on changing out hard drives, as this is usually the point that UUID’s bite you on the butt?
Gary, any special problem you have in mind? I mean, if you change the root partition you usually have to re-install the system anyway…
The problem arises mainly when you are using system imaging. Lets suppose I want to put the same image on multiple machines. The UUID is generated during format. So if you format the drive in the new machine and then copy all the files over, the files now refer to a UUID that doesn’t exist. If I can copy the partition information over as well, then formatting isn’t necessary and the UUID will be the same. But complex disk setups, like with brtrfs or LVM tend to make things very difficult. There really should be a way to dictate a UUID when formatting.
Gary, good point: I added a part about using tune2fs for settings uuids. =)
Thanks! Just one question: Where is the UUID stored? I presume the UUID is generate the first time we plug (or install) the device but the next times?
Good one – it is stored in the superblock, I updated the article correspondingly.
From the same Wikipedia article you cite:
“A UUID is a 16-octet (128-bit) number.”
That’s a 32-bit width, not 16.
I wrote “16 byte wide”, which is correct: the Wikipedia article and also the RFC both state the octet is 128 bit wide, and that is in fact 16 byte.
But I will correct the article to reuse the wording of the Wikipedia article and the RFC.
You need to brush basics busterville 🙂 you are half right ..it is 32 but nibble
Hello!
Thanks for the info.
How can one set the UUID, if the file system is not ext? For example, fat.
Depends on the file system. VFAT does not have a UUID as such, afaik. But the mtools’ mlabel can be used to change the serial number.
I don’t know about LVM but you can absolutely have duplicate UUIDs when working with btrfs. Here is a line right out of an fstab from a media box
Obviously the UUID is the same because its the same FS being mounted twice with different subvolumes.
That’s true – thanks for pointing that out. I added a comment in the text and referenced your comment here.
But this is a rather special case – if you mount normal volumes you might again might get into trouble…
You are right, it’s a special case, I just thought I’d mention it to round out your excellent article!
You can also use dumpe2fs
sudo dumpe2fs -h /dev/sdb1 | grep UUID
Nice, I did not knew about that one!
Why is the LVM2 PV UUID in a different form that is twice as long as a normal UUID. Where is this other format defined and what do you call it since it is not really a RFC4122 UUID.
That is a very good question – and so far I was not able to figure out any answer! If I ever come across a reasonable explanation I’ll let you know.
Actually generate_random_uuid() had been moved to lib/uuid.c in v4.7.
https://elixir.bootlin.com/linux/latest/source/lib/uuid.c#L41
P.S. Yes, and better to use Elixir source code explorer than Linus’ official Git repo.
Thanks for the update!
And yes, Elixir looks much better, but I prefer to link to kernel.org directly 😉
hi I am try to generate uuid in RHEL 7.2 but no value is return.
command : /usr/lib/udev/scsi_id -g -u -d /dev/sdc ==> no value retun
even try other commands also, but still non of them works.
blkid /dev/sdc
ls -l /dev/disk/by-uuid
I need to step udev rules for oracle asm disk. and i need to know uuid for these specific disk like /dev/sdc, /dev/sdd etc. Any help ? thanks in advance.
Troubleshooting is difficult to do in blog like this.
How about an alternative: since it is a RHEL you can just create a support ticket with Red Hat, and ask for help. That’s totally ok and shows the true value of the subscription, after all 😉
But you can also post the problem to serverfault to get help. I’d be happy to have a look at it there as well if you let me know the link.
Thank you for this excellent and accurate information. I’ve been working on restoring a Centos 7 distro from an rsync backup, just practice for work before things go very wrong. I’ve figured out not to overwrite, or to change the reference to the UUID in /etc/fstab from the old system, as obviously the new disk will not match. My question and reason for reading your article, which may help myself and others in this process is this: Are there any other UUID’s in a running file system that may give me the same type of problem? I’ve been thinking no, assuming all other hardware is the same but from what I learned here today, a new install may generate other new random UUID’s for hardware that wouldn’t match the old system. Or does that just happen at boot for all other hardware? I wonder if there is a directory that I could just exclude during rsync restore so that the new system would keep the correct UUID’s. Thank you all in advance for any knowledge you are able to pass along to help.
That’s a good question. I would certainly check your udev rules if there are any which might cause a problem.
But apart from those I would not expect any other major roadblock related to UUIDs…
Reblogged this on hegelianblog.
what the heck have i did wrong now
Meant to share, not to reblog. Apologies.
Thanks for sharing this and letting me know, I appreciate it!
A very minor clarification suggestion:
You say “For the block device itself, the uuid is stored in the superblock.”. The first time I read this I was thinking of the case where you have a disk, say /dev/sda, that contains several partitions, say /dev/sda1 and /dev/sda2. To me, the “block device itself” is /dev/sda, and the others are block partition devices which might or might not contain file systems. With this in mind, it isn’t correct to say that the block device itself stores the uuid in the superblock because the block device itself, again /dev/sda, doesn’t contain a file system, and only file systems contain superblocks. Also, not every partition device contains a file system, so the ones that don’t won’t have a uuid.
Maybe it would be better to say something like “For block devices containing file systems, the uuid is stored in the file system’s superblock.”
Otherwise, nice job.