☰

当 /dev/disk/by-uuid 中未列出时，如何查看系统中磁盘的 uuid

tag-icon • tag-icon disk storage uuid
当 /dev/disk/by-uuid 中未列出时，如何查看系统中磁盘的 uuid

我的系统有一个我不明白的问题：没有磁盘 UUID，只有分区 UUID:

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

知道该怎么做吗？看到磁盘 uuid 了吗？

稍后编辑：（作为对评论的回应）

磁盘确实有 UUIDS，首先我自己确实看到了它们，即使是在我自己的系统中，然后由于某种原因消失了，而不仅仅是相信我的话（是的，我的话似乎很模糊“我看到了海市蜃楼” ") ...这里有一些使用磁盘 uuid 而不是分区的 ppl 链接：

linux：如何查看系统上所有可用磁盘的所有 UUID？

底部第二个答案

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

和

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

楼上的第二个答案：

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

之后还有两个答案

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

我真希望没有人过来说hdparm是用在分区上的……

所以，感谢您的兴趣，我个人“祝贺”那些似乎足够相信您并为您的明显错误答案评分的人！

答案1

sgdisk 这样做：

# 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

答案2

还有一个文件夹叫/dev/disk/by-ID/

所以你可以运行

ls -l /dev/disk/by-id

按 ID 获取设备列表，其中包括驱动器，而不仅仅是分区。

请注意，如果将设备插入不同的控制器或控制器成为不同子系统的一部分，则其中一些 ID 可能会更改。

如果您的设备支持它，那么那里有一些特殊类型的 ID，即所谓的 ID全球通用名称 (WWN)或者全球标识符 (WWID)类型。这些 ID 确实是唯一且不变的，因此您可以使用它们来可靠地识别您的驱动器。他们从 开始wwn-。

因此，假设您使用的是 debian 或衍生版本，您可以使用类似的块

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

为您唯一标识的磁盘设置 hdparm 参数。

关于不同类型的持久块设备名称的更多内容请参见这里。

答案3

符号/dev/disk/by-uuid/*链接很可能是由 udev 规则创建的，不同的发行版（甚至同一发行版的不同主要版本）可能有稍微不同的规则。

在我的 Debian 10 系统上，这些符号链接是由/lib/udev/rules.d/60-persistent-storage.rules.文件的开头写道：

# 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 <[email protected]>

因此看来这个约定最初可能是由 SuSE Linux 发明的。

该文件中只有一条规则创建by-uuid符号链接：

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

请注意，这使用环境变量引用文件系统 UUID仅有的。

分区 UUID（GPT 分区表中的实际 UUID，或通过组合（可选）Windows 磁盘签名和 MBR 分区表中的分区号创建的字符串）由另一个规则使用不同的路径创建：

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

由于共同的出身，我希望 Ubuntu 和 Mint 具有几乎相同的规则。

我会冒险猜测这些 udev 规则的早期版本可能会在单个/dev/disk/by-uuid目录中为所有类型的 UUID 创建符号链接。但是，浏览具有多种类型的 UUID 符号链接（文件系统 UUID、分区 UUID 和磁盘 UUID）的目录会使其更难使用：对于通过 UUID 找到的每个设备，您必须弄清楚是否需要期望分区表是否在该设备上。由于这已经由内核完成，因此这将是无用的重复工作。因此，该方案在某个时候进行了细化，以将文件系统 UUID到/dev/disk/by-uuid/，分区 UUID到/dev/disk/by-partuuid/。

GPT 和 MBR 分区表中的磁盘 UUID 只是在创建分区表时创建的“软件”标识符，并且可以更改。因此，任何依赖于磁盘 UUID 的内容都会被全磁盘映像所欺骗：例如，如果您这样做dd if=/dev/sdx of=/dev/sdy，则sdx和都sdy将具有相同的 UUID，包括磁盘 UUID。磁盘 UUID 不能用于挂载，因为它是分区表的一项功能，不包含指定分区的方法。通过用零或随机字节填充来擦除的磁盘没有有效的分区表，因此既没有分区也没有磁盘 UUID。

由于 MBR 分区表没有真正的 UUID，因此生成 MBR 磁盘和分区“UUID 替代”字符串的方式允许您向 MBR“磁盘 UUID 替代”添加减号和两位数的分区号以获取 MBR “分区 UUID 替代”。对于任何其他分区方案都不是这样，因此您可能不应该依赖此功能。

如果您尝试识别物理磁盘，则使用可在 中找到的基于硬件/固件的磁盘序列号/dev/disk/by-id将是区分具有相同（克隆）内容的两个磁盘的更可靠方法。此类序列号将在任何正常的磁盘克隆和擦除过程中保留下来：只有对磁盘固件的实际修改可能会更改它们。

相关内容