What's the difference between UUID and PARTUUID?

Question

I've followed the procedure in the raspberry pi forums to make my Raspberry Pi 3 use an USB key instead of the SD card as root filesystem in the hope to make it more robust to power loss.

The process worked, but I lost time because I confused UUID and PARTUUID for partition (use blkid and see how they can be different). What's the purpose of both? It was simpler to fix my confusion by using UUID instead of PARTUUID everywhere, but that failed, I had to use PARTUUID (I think it would have been possible to use a mix, but I didn't try to search for one).

Note that the cited page hints that the UUID is for the drive is PARTUUID for the partition, but then I'd expect that the UUID be the same for all partitions of a drive, that's not the case.

Answer 1

On Difference between UUID and PARTUUID

You can get a few hints about the difference between UUID and PARTUUID by specifying the -p option.

blkid -p /dev/sda1

or whatever device/partition you are looking at. You may have noticed that if there are multiple partitions on the same UUID device, the PARTUUID is mostly the same with the partition number appended.

A UUID is guaranteed to be unique. As far as I know, collisions will not happen within the lifetime of the universe. However, you'll note that the PARTUUID is much shorter. These are meant to be "locally" unique, and collisions most likely occur between all known PARTUUIDs.

On UUIDs

A UUID is simply a unique identifier. They are used for many different purposes. You can generate them using the uuidgen function.

For further reading about UUIDs:

$man uuidgen 

Or Internet:

manpage for uuidgen

Some more UUID use examples

$cat /etc/fstab

For newer GNU/Linux systems, you'll have a list of all the partitions and their UUIDs. A new UUID is generated for each new partition. So, if re-partition a given drive, all the blkid UUIDs for that drive will change.

Part of the reason UUIDs are used as identifiers of partitions and drives is to maintain identifiers even when drives are added or mounted in a different order. In a prior time, the fstab would have identifiers such as /dev/sda1 ... This had the disadvantage of possibly having sda1 be a physically different drive or partition if somehow the mount order was changed.

On PARTUUIDs

PARTUUIDs are a component of GUID Partition Tables (GPT) which are a replacement for Master Boot Record (MBR) related disk partitioning.

For further reading see Linux.com - Using the New GUID Partition Table in Linux

Linux.com says:

The GPT GUIDs (Globally unique identifiers) and our familiar Linux UUIDs (Universally Unique Identifiers) are not the same thing, though they serve the same useful purpose: giving block devices unique names. Linux UUIDs are a function of filesystems, and are created when the filesystem is created. To see Linux UUIDs just fire up the blkid command Note the Partition GUID code, and how it says "Microsoft basic data." Yeah, ole Microsoft always party-crashing, because this an EXT4 partition, so there is no way for Windows to read it, but will see it as an unformatted partition. You won't see this with current releases of gdisk, because until 2011 there were no Linux filesystem GUIDs. Now there are, so if you're not using an old Linux like mine (Mint 13) you'll see a proper Linux GUID instead (0FC63DAF-8483-4772-8E79-3D69D8477DE4).

The Partition unique GUID is what you'll use in fstab, like this:

PARTUUID=8C208C30-4E8F-4096-ACF9-858959BABBAA /data ext4 user,defaults 0 0

Answer 2

As I understand it.

The term UUID in general refers to a "Universally unique identifier", known in the windows world as a GUID. There are a few different schemes but for the most part modern UUIDs/GUIDs are essentially a big random number or hash and a few flag bits.

In the specific case of mounting filesystems on linux "UUID" reffers to a unique identifier that is part of the metadata stored inside the filesystem. "PARTUUID" refers to a unique identifier for a partition stored in or derived from the partition table.

These unique identifiers may or may not be actual UUIDs. As far as I can tell.

• For GPT partition tables the "PARTUUID" is the GUID from the GPT partition table.
• For MBR partition tables the "PARTUUID" is formed by concatenating the disk identifier with the partition number
• For EXT4, Linux swap, BTRFS and probablly other linux-native filesystem types the "UUID" is a UUID stored in the filesystem metadata.
• For FAT and NTFS the "UUID" appears to be the volume serial number, 32 bits for FAT and 64 bits for NTFS.

Note that support for mounting the root filesystem by "UUID" and "PARTUUID" varies. IIRC the kernel running without an initrd can mount by "PARTUUID" but not by "UUID". Older versions of initramfs-tools can mount by "UUID" but not "PARTUUID", recent initramfs-tools supports both.

Answer 3

It is about layers of abstraction.

The core difference is physical-storage vs logical-storage identification. The PART-UUID is for raw physical storage partitions and is a feature of GPT partition tables. A UUID is for identifying logical file systems, it is generated by the creation of the filesystem such as mkfs.ext4, and then refers to the formatted filesystem not the raw physical partition.

Which one to use depends on your priority, do you want to track physical storage device partitions or do you want to track filesystems?

Use PART-UUID to link to a physical drive partition even if you format it with a new filesystem, this is closest to the old behavior of using /dev/sda4 eg. This does not work for mounting logical volumes if you use LVM2 for example; but PART-UUID can be used within LVM2 for referring to physical storage within a storage pool or physical units in a RAID.

Use UUID to link to a specific filesystem, the filesystem must support it, as such FAT and NTFS which predate the UUID industry standards do not support the common UUID standard.(They do have unique identifiers but formatted different and shorter than a common UUID, Linux will accept them in most cases.) If you bit>bit clone the filesystem to a new physical drive partition the UUID will follow, the PART-UUID will not follow. (You must disable or remove the old copy from the system or there may be a collision.) UUID works with logical volumes and raid volumes,(volume here being a logical filesystem not a physical device) a raid1 btrfs filesystem when scanned with blkid will have unique PART-UUID for each disk partition in the pool but all of them will have the an identical UUID, but then you will also see UUID_SUB (btrfs has its own form of internal logical partitioning called sub-volumes.)

Linux mkswap will generate and assign a UUID to a raw swap partition even though there is no true filesystem involved, but this UUID will change every time you run mkswap on that partition, while the PART-UUID will stay the same.(This example is easy to test even if you keep swap off.)

If you mix the two ID types in fstab, there is a very small chance that a collision could happen; though it is minor and easy to fix unless it involves / or /boot. Example: If you originally use PART-UUID to mount sda4 on /var/cache/apt and you use a UUID to mount the filesystem you use for /home. Then at some point in the future you clone /home onto sda4 and fail to fully correct fstab, then fstab will now have two totally different mount instructions for the one physical filesystem-partition and will not know if you want it on /home or /var/cache/apt. (Or possibly some other undefined behavior I'm not an init-fstab-mount-systemd expert.) The fix is simply to delete the unwanted line from fstab.

Microsoft calls its special format of UUID a GUID, it serves the same purpose and is included in the industry standards as a UUID variant for backward compatibility.

As for your specific issue I can only think of three possibilties why one ID would work and not the other. It is possible the specific file system in use does not generate a UUID. Secondly the choice of MBR vs GPT for the partition table, MBR does not generate a PART-UUID. The third is just an error like one wrong character. to avoid the third i like to add partitions to the fstab [after making a backup copy] with sudo blkid /dev/sda4 >> /etc/fstab to get the IDs into the file exactly and then manually edit fstab to format the mount instruction. (> is over write, >> is append, be careful)

Do not confuse any of this with a partition-type-GUID which is just a fixed code in a GPT partition table for the exact type of partition and filesystem use. MBR had simple codes but there was not enough room so they were not globally unique codes and had a lot of overlapping uses or covered whole generic categories like "linux filesystems". While a GPT part-type-GUID has more than enough space so that the code for "Solaris /home" is different from "linux /home" or "freeBSD ZFS" or "Plan9 data" etc. But all "Solaris /home" partitions will have the same part-type-GUID.