1

I have a problem in my system, that I don't understand: there are no disks UUIDs, only partitions UUIDs:

ls -al /dev/disk/by-uuid/
total 0
drwxrwxrwx 2 root root 140 Nov 21 20:36 ./
drwxrwxrwx 5 root root 100 Nov 21 20:36 ../
lrwxrwxrwx 1 root root  10 Nov 21 18:36 20AC094AAC091C42 -> ../../sda3
lrwxrwxrwx 1 root root  10 Nov 21 18:36 A004AFE104AFB8A4 -> ../../sda2
lrwxrwxrwx 1 root root  10 Nov 21 18:36 E83A6F543A6F1EB6 -> ../../sdb1
lrwxrwxrwx 1 root root  10 Nov 21 18:36 FE6CD3A96CD35ACB -> ../../sda1
lrwxrwxrwx 1 root root  10 Nov 21 18:36 e6c45231-5e3d-4874-8294-df43b55e8fea -> ../../sdb2

any ideea what to do ? see disks uuids ?

Later Edit: (as response to a comment)

DISKS DO HAVE UUIDS, first of all I did see them myself, even in my own system, then for some reason was gone, and not just to take my word for it (yes, my word seems to be vague "I saw the mirage") ... here some links with ppl using disks uuids NOT partitions:

linux: How can I view all UUIDs for all available disks on my system?

second answer from bottom

lrwxrwxrwx 1 root root  9 Sep  1 18:51 b4b729f7-5699-411c-8f5a-424bbc7c89fc -> ../../sdb

and

https://askubuntu.com/questions/39760/how-can-i-control-hdd-spin-down-time

second answer from the top:

hdparm -S 25 /dev/disk/by-uuid/f6c52265-d89f-43a4-b03b-302c3dadb215

and two ansers after that

hdparm -S244 /dev/disk/by-uuid/71492809-e463-41fa-99e2-c09e9ca90c8e  > /dev/null 2> /dev/null

I really hope no one will come and say that hdparm is used on partitions ...

so, thank you for your interest and my personal "congratulations" to the ones who seems to believe you enough to give you rating for an OBVIOUS WRONG ANSWER !

5
  • 3
    There's nothing wrong with your system. UUIDs are assigned to filesystems (partitions) not to disks, you could use the serial number though if you have to reference the whole disk... – don_crissti Nov 21 '15 at 19:57
  • LUL, check the later edit – THESorcerer Nov 21 '15 at 20:47
  • 1
    You do know that some programs are smart enough to see when they have been given a partition and go for the actual disk containing that partition? As for that U&L post, clearly people don't usually bother to distinguish between disks, drives and partitions, unless the question calls for it. Your question does. – muru Nov 22 '15 at 2:59
  • yes, maybe, but ... you are kinda' off-topic, be cuz, I think I proved good enough that there are disk uuids and therefore ... where are they ? :) – THESorcerer Nov 22 '15 at 10:17
  • What (numeric) version of udev does your system have? – Mark Plotnick Nov 23 '15 at 2:02
1

sgdisk does this:

# sgdisk -p /dev/xvda
Disk /dev/xvda: 16777216 sectors, 8.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): B9181609-5D44-49F4-9CD6-DEDBA25FC478
0

There is also a folder called /dev/disk/by-id/

So you can run

ls -l /dev/disk/by-id

to get a list of devices by their IDs, which includes drives, not only partitions.

Careful, some of these IDs can change if you plug the device in a different controller or if the controller becomes part of a different subsystem.

If your device supports it though, there are some special types of IDs there, of the so-called World Wide Name (WWN) or World Wide Identifier (WWID) type. These IDs are truly unique and unchanging, so you can use them to reliably identify your drives. They start with wwn-.

So, supposing you are using debian or a derivative, you could use a block like

/dev/disk/by-id/wwn-0x5...1 {
    spindown_time = 24
    apm = 254
    apm_battery = 254
    acoustic_management = 128
}

to set hdparm parameters for your uniquely identified disk.

More reading about the different types of persistent block device names can be found here.

0

The /dev/disk/by-uuid/* symlinks are most likely created by udev rules, and different distributions (or even different major releases of the same distribution) can have slightly different rules.

On my Debian 10 system, these symlinks are created by /lib/udev/rules.d/60-persistent-storage.rules. The beginning of the file says:

# do not edit this file, it will be overwritten on update

# persistent storage links: /dev/disk/{by-id,by-uuid,by-label,by-path}
# scheme based on "Linux persistent device names", 2004, Hannes Reinecke <hare@suse.de>

So it appears this convention may have been initially invented by SuSE Linux.

Only one rule in that file create by-uuid symlinks:

ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID_ENC}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"

Note that this uses environment variables referring to filesystem UUIDs only.

Partition UUIDs (actual UUIDs in a GPT partition table, or strings created by combining an (optional) Windows Disk Signature and a partition number in a MBR partition table) are created by another rule, using a different path:

ENV{ID_PART_ENTRY_UUID}=="?*", SYMLINK+="disk/by-partuuid/$env{ID_PART_ENTRY_UUID}"

By common parentage, I would expect Ubuntu and Mint to have pretty much the same rules.

I would hazard a guess that early versions of these udev rules might have created symlinks for all types of UUIDs in a single /dev/disk/by-uuid directory. But walking through a directory that has several types of UUID symlinks (filesystem UUID, partition UUID, and disk UUID) makes it harder to use: for each device you find by UUID, you would then have to figure out whether you need to expect a partition table on that device or not. Since that is already done by the kernel, that would be useless duplication of work. So the scheme was refined at some point to separate filesystem UUIDs to /dev/disk/by-uuid/, partition UUIDs to /dev/disk/by-partuuid/.

Disk UUIDs in GPT and MBR partition tables are just "software" identifiers created at the time of creation of the partition table, and they can be changed. So anything that relies on a disk UUID will be fooled by a full-disk image: for example, if you do dd if=/dev/sdx of=/dev/sdy, then both sdx and sdy will have the same UUIDs, including the disk UUIDs. A disk UUID cannot be used for mounting, as it is a feature of the partition table and does not include a way to specify a partition. A disk that has been wiped by filling it with zeroes or random bytes does not have a valid partition table, and hence neither partition nor disk UUIDs.

Since a MBR partition table has no real UUIDs, the way the MBR disk and partition "UUID substitute" strings are generated allows you to add a minus sign and a two-digit partition number to a MBR "disk UUID substitute" to get a MBR "partition UUID substitute". This is not true on any other partitioning scheme, and so you probably should not rely on this feature.

If you are trying to identify physical disks, using hardware/firmware-based disk serial numbers that can be found in /dev/disk/by-id would be a much surer way to tell apart two disks with identical (cloned) contents. Such serial numbers will survive any normal disk cloning and wiping procedures: only actual modifications to the disk firmware might change them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.