You are not logged in.
Wiki says:
Note: Please notice the difference between the standard UUID and the PARTUUID shown by $ ls -l /dev/disk/by-partuuid/
So what's the difference?
Last edited by x-yuri (2013-06-12 16:30:10)
Offline
PARTUUID/PARTLABEL identifies a GPT partition. UUID/LABEL identifies a filesystem.
PARTUUID/PARTLABEL have the advantage that they don't change if your reformat the partition with another filesystem. It's also useful if you don't have a filesystem on the partition (or use LUKS, which doesn't support LABELs).
Offline
And UUID/LABEL are stored inside partitions, as opposed to PARTUUID/PARTLABEL, right? Come to think of it, do windows partitions have UUID too?
Offline
And UUID/LABEL are stored inside partitions, as opposed to PARTUUID/PARTLABEL, right? Come to think of it, do windows partitions have UUID too?
UUID/LABEL are part of the filesystem, so I guess you could say they are stored inside the partition, yes.
NTFS and FAT32 partitions have UUIDs as well (although they are much shorter).
Offline
It appears FAT's and NTFS's UUIDs are not true UUIDs, whatever it means :)
All Linux filesystems support filesystem UUIDs; FAT and NTFS filesystems don't support true UUIDs, but are still listed in /dev/disk/by-uuid with a unique identifier
http://wiki.debian.org/Part-UUID#Via_UUIDs
Also, I'm trying to comprehend how LVM and LUKS fit into the picture... As far as I can tell, they are not filesystems, like ext4 or ntfs. They are transparent containers. The data itself are stored inside these containers. Containers are basically responsible for knowing how to get the data. Therefore, how come LUKS can support LABELs? I thought LABELs are part of a filesystem, aren't they?
Last edited by x-yuri (2013-06-12 13:20:29)
Offline
Also, I'm trying to comprehend how LVM and LUKS fit into the picture... As far as I can tell, they are not filesystems, like ext4 or ntfs. They are transparent containers. The data itself are stored inside these containers. Containers are basically responsible for knowing how to get the data. Therefore, how come LUKS can support LABELs? I thought LABELs are part of a filesystem, aren't they?
As I said, LUKS does not support LABELs. It does however support UUIDs which are probably just stored in the LUKS header (see cryptsetup luksDump).
no idea about LVM.
Offline
LVM pvs have headers, not sure about vgs and lvs though.
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
Ok, let me tell you the picture the way I see it for now.
First, there are GPT and MBR, which define the format of the whole physical drive, except for partitions themselves. They may contain PARTUUIDs/LABELs. Then, there may be intermidiate levels like LVM or LUKS, which may have UUIDs/LABELs assigned to their "subpartitions". And finally there are filesystems, which may have UUIDs/LABELs.
Then, particularily, LUKS supports UUIDs, but doesn't support LABELs; all linux filesystems supports UUIDs; FAT and NTFS doesn't support true UUIDs, whatever it means (either they have some ids, or ids are somehow assigned by the kernel).
Offline
sda3 on my system has a UUID. This is LVM on LUKS. Each volume within the LVM then also has a UUID.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
btw,
/dev/sda3: UUID="12nTBU-FlXK-QJcW-Nc2s-VSHl-Gke8-eshAkl" TYPE="LVM2_member" PARTLABEL="Linux LVM" PARTUUID="f023329c-d1b7-42a4-a1bf-9745ef2fbcea"
/dev/mapper/VolGroup00-lvolroot: UUID="9d3e54fe-57a9-4ac3-823b-5fcd2c4fc9f2" TYPE="ext4"
As such, one can't use PARTUUID for lvm volumes.
Offline