Use udev for partition UUID #320
Conversation
| @@ -540,8 +540,10 @@ Each `ghw.Partition` struct contains these fields: | |||
| * `ghw.Partition.Disk` is a pointer to the `ghw.Disk` object associated with | |||
| the partition. This will be `nil` if the `ghw.Partition` struct was returned | |||
| by the `ghw.DiskPartitions()` library function. | |||
| * `ghw.Partition.UUID` is a string containing the volume UUID on Linux, the | |||
| partition UUID on MacOS and nothing on Windows. | |||
| * `ghw.Partition.UUID` is a string containing the partition UUID on Linux, the | |||
There was a problem hiding this comment.
ok, so for my understanding we are changing from volume UUID to partition UUID? If so, there are practical implications of this change?
There was a problem hiding this comment.
Not really, they are the same uuid afaik, only this is worded weirdly by mentioning volume for some reason. On my local checks, the values given by lsblk were the same as the ones on udev.
I can check further tonight to confirm this.
There was a problem hiding this comment.
thanks, I'll also do my homework and learn a bit more about this area
There was a problem hiding this comment.
UUID comment seems to confirm that this is indeed the partition UUID, probably the Volume name comes from also adding the MacOS UUID, which is the Volume UUID:
UUID string json:"uuid" // This would be volume UUID on macOS, PartUUID on linux, empty on Windows
And yes, this seems to be the same value as what blkid reports for PARTUUID. Note that there is also a ID_PART_TABLE_UUID which points to the disk UUID, which we should not confuse with this.
And to further confirm that this is indeed the expected value, if you do a low lovel probe with blkid, it will show the actual PART_ENTRY_UUID value, which is mapped by udev to the ID_PART_ENTRY_UUID but for some reason is named different when presented to the user:
$ sudo blkid /dev/nvme0n1p2 --probe
/dev/nvme0n1p2: PART_ENTRY_SCHEME="gpt" PART_ENTRY_UUID="659f38f6-ec95-4e92-88f7-15993d5b3d61" PART_ENTRY_TYPE="21686148-6449-6e6f-744e-656564454649" PART_ENTRY_NUMBER="2" PART_ENTRY_OFFSET="1026048" PART_ENTRY_SIZE="16384" PART_ENTRY_DISK="259:0"
And you can see that matches the actual udev contents:
$ cat /run/udev/data/b259:2|grep ID_PART_ENTRY_UUID
E:ID_PART_ENTRY_UUID=659f38f6-ec95-4e92-88f7-15993d5b3d61
And output without a low level probe:
$ sudo blkid /dev/nvme0n1p2
/dev/nvme0n1p2: PARTUUID="659f38f6-ec95-4e92-88f7-15993d5b3d61"
There was a problem hiding this comment.
thanks @Itxaka this fully makes sense to me. I just need to spend some extra time to learn myself a bit more. I'll review ASAP but in general LGTM (and I totally, really like this direction!)
README.md
Outdated
| * `ghw.Partition.UUID` is a string containing the volume UUID on Linux, the | ||
| partition UUID on MacOS and nothing on Windows. | ||
| * `ghw.Partition.UUID` is a string containing the partition UUID on Linux, the | ||
| partition UUID on MacOS and nothing on Windows.On Linux |
There was a problem hiding this comment.
femto-nit: Can you add a space after Windows. and before On?
This allows us to drop the use of blkid completely and on linux fully report all the data rootless. Signed-off-by: Itxaka <igarcia@suse.com>
Signed-off-by: Itxaka <igarcia@suse.com>
This allows us to drop the use of blkid completely and on linux fully
report all the data rootless.
Closes #319
Signed-off-by: Itxaka igarcia@suse.com