I realized that my understanding of UUIDs in Linux to specifying hard disk partitions may be erroneous.

The proverbial wisdom is that one should not use hard-coded device specifications in fstab and in the boot menu.lst, such as /dev/sda1 etc. The reason normally given is that if hard disk order changes or the order of partitions change, then the entries will be incorrect since they are hardcoded to partitions following a specific order.

So my understanding was that using hard disk labels, in the form of LABEL=xxxx, or UUIDs in the form of UUID=some-uuid, would prevent these problems when disk order or partition order changed.

I decided to avoid the use of LABEL in case I wanted to change the LABEL on a partition to make the names of partitions more easily identifiable. I then thought that UUID was ideal since it never changed for a partition no matter even if I moved that partition to another drive or added another hard drive and thus changes the order of hard drives on my computer. I essentially thought that once UUID was determined for a partition, it never changed but was somehow part of the partition in the hardware of my computer.

Then I became curious of how a UUID was determined. I did this because I often make backups of partitions on external SATA drives and wanted to make sure that somehow the backup would not duplicate whatever Linux considers the UUID of a partition and present a Linux distribution with two UUIDS which are somehow the same and therefore confuse the Linux distribution to the point that I could not use it. I am aware that UUID means a unique id, but I wanted to make sure I understand how that unique id is determined in Linux. This is especially true since the tool I use to make backups of an entire partition is a Windows application, and not a Linux application, and I wanted to make sure that the backup partition UUID would not duplicate that of an existing partition.

In my very brief research in how a UUID is generated under Linux it appears that it is not something that is part of the hardware of the partition itself but rather a number generated by some parameters of the partition, one of which is the partition order.

Is this correct ?

If it is, it means to me that if I move a partition from one place to another, even on the same hard drive, or to another hard drive, a Linux distribution will no longer find the partition based on the UUID. In that case it seems as if the UUID is subject to the same weakness as the device specification in fstab and menu.lst in that the order of a partition or the placement of a partition on a particular hard drive will cause the designation to no longer refer to the same partition. In which case it appears to me that only the LABEL parameter is not subject to this weakness and as long as I keep distinct labels for all partitions on my hard drive I could theoretically move them around at will and a Linux distribution will find them correctly. I am aware of course that my computer must always find the boot partition to be able to boot a Linux distribution, so moving Linux parttions where I want them is subject to the ability of my computer to find them from the MBR of my hard drives. But in the main it now appears to me that the best way to insure that moving partitions does not keep a Linux distribution from botting correctly is to use LABEL, and not UUID, in fstab and menu.lst, and of course to make sure that if I decide to change the LABEL of a partition that I must change its entry in fstab and possibly menu.lst before rebooting that distribution.

If I have been wrong in my latest surmises I would appreciate being corrected, as the information I found on UUIDs and how they are generated may not be correct. Also if there is more exact information on exactly how partition UUIDs are generated in Linux I would appreciating anyone pointing it out to me.

Thanks !

UUID is used a lot. You can find UUIDs in the volume labels of most partitions, the LVM logical volume metadata, but you can also find UUIDs used in LVM Physical Volume, and Volume Group metadata, too, I think.

Yes, the UUID is not hardware based. I'm not sure what it is generated from, but the whole point of a UUID is that each one generated is unique, sort of like a fingerprint. (But it's not immutable so you could change the UUID in a volume label to anything you wanted or needed it to be.)

I think it depends on how you move it. If you used a utility (like Partition Magic under Windows) then moving it would have no effect on the UUID. If you used 'dd' under Linux to copy it to a new location you would be copying the existing UUID (and the ext2/3 LABEL, too). So you could potentially have two partitions with the same UUID and ext2/3 LABEL.

If you did a file based copy, like rsync or tar, the UUID and LABEL of the underlying partition are naturally unaffected.

I think the UUID is generated and placed in the label when the mkfs (mkfs.ext3 or whatever) of the filesystem is done. I don't know the details. Maybe someone more knowledgable can elaborate and correct any of my misinformation.

The vol_id command can show you what the UUID and ext2/3 LABEL of a particular filesystem is.

AFAIK a UUID is just a random number generated and assigned as previously posted when the filesystem is created. There are several methods that can be used to generate UUIDs but it is not going to change unless you manually do so. As also stated cloning creates an exact copy so it will also have the same UUID and label.

Where is the partition UUID kept in Linux ? Since each Linux distribution I run appears to use the same UUID for the same partition, then it must either be generated each time using the same algorithm for each distribution, and kept internally in memory, or it is physically written to and read from the partition in some way.

If I do backup a partition using my Windows program to do so, and the UUID is part of the partition itself, I need to make sure that I can tell the backup program to produce another UUID for the backed up partition since the external Sata to which I backup a partition normally stays mounted when I reboot into a particular Linux distribution, and I do not want Linux to see two partitions with the same UUID and become hopelessly confused.

Your answer implies that the UUID is part of the volume label, meaning it is part of the hardware once Linux generates it, and is written to and read from the partition ( or the hard disk partition table ) itself. Is that true ?

I need to know because if I backup my Linux partitions to my ESata hard disk I need to make sure that the backup has a different UUID than the original, since my ESata normally remains mounted as I boot into a Linux distribution on my computer.

I guess volume label probably is not a technically accurate term and I shouldn't have used it. In an ext2/3 filesystem, the UUID and LABEL are saved in the Superblock.

Well, not really so much "part of the hardware" but yes, it is "written to and read from the partition".

(btw, the partition table entries are just 16 bytes long and don't contain very much - active flag, start and stop addresses of the partition - both c/h/s and LBA form.)


Just for reference, here is the /etc/fstab entry to mount /boot, and a dump of the /dev/sda1 superblock.

The fstab entry could have been
I don't know the advantage of UUID= over LABEL= in /etc/fstab, but UUID seems to be preferred by a lot of people. I guess because it is generated automatically instead of manually, it more likely to be unique.

What are you using to do your backups?

"What are you using to do your backups?"

I am using a Windows program called Paragon Partition Manager. I will find out from them whether I can change the UUID of the backed up Linux partition, or if they automatically change it when they backup a Linux partition. If not I will look to do backups of Linux partitions from Linux instead.

"What are you using to do your backups?"

In Paragon Partition Manager the UUID is called the Serial Number and it can be changed at any time so I now know what I have to do when I make a backup.

Thanks very much for your help. It looks like UUIDs are the way to go since once they are written to the superblock they do not change unless one specifically changes them. So if I want to move around my none-boot partitions Linux should always continue to find them as long as I use UUIDs in fstab and menu.lst. I can see now that UUID are a superior idea and Linux was correct in adopting them for partition identification.