在同一型号的工业 PC 上,我看到主 SSD 的 UUID 发生了变化。这 2 个 IPC 是从 2 个相似但不同的 Linux 磁盘映像恢复的。问题如标题所示。主盘UUID/dev/sda2
不同。
- 都是 Ubuntu 16.04。
- Linux 磁盘映像 A:内核 4.15.0-65。 UUID
bc96e844-27c1-4ccb-af66-053cce7cecdb
。用户m、n存在。用户 n 的主文件夹已加密。 - Linux 磁盘映像 B:内核 4.15.0-96 UUID
19e10365-d0b9-44c1-ac5d-a7acd5941bae
。用户m仅存在。有些软件包较新。
顺便说一句,我们用磁盘映像 A 制造了许多 IPC。虽然我没有检查所有 IPC,但我只是随机检查了一些,它们都显示相同的 UUID。
在从映像 A 恢复的一台主机上,/var/log/syslog
输出以下 UUID:
Apr 16 13:59:03 poodle_noodle kernel: [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-58-generic root=UUID=bc96e844-27c1-4ccb-af66-053cce7cecdb ro quiet splash vt.handoff=7
:
(事实上,在上面的日志中,我正在做一些实验,所以Kernel版本是4.15.0-58,甚至不是4.15.0-65,但UUID是相同的。所以排除了这个Kernel版本)
在从镜像B恢复的主机上:
$ sudo blkid
:
/dev/sda2: UUID="19e10365-d0b9-44c1-ac5d-a7acd5941bae" TYPE="ext4" PARTUUID="d1cf8631-f3f7-4b8d-baba-86c6fcebe232"
:
答案1
更新:
这就是发生的事情。这些映像本身就是带有分区和文件系统的原始磁盘的副本。然后,磁盘布局、文件系统、内容等都将写入您要创建映像的计算机上的磁盘。在某个时候,有人运行 mkfs 来创建图像上使用的文件系统,并生成了一个 UUID。这些映像具有彼此不同的 UUID,因为它们是根据不同文件系统的内容生成的。这是有道理的,因为您通常会进行全新安装,然后重新分区/重新格式化以生成映像。
这种情况只会发生在基于映像的安装上,当您执行正常的 (install-root/debootstrap/pacstrap/etc/) 安装时,您通常会重新格式化以删除旧内容,从而为新文件系统生成新的 UUID。
老的:
我不是 100% 确定我理解这个问题,但我解析的方式是:我有两台相同型号的 PC,为什么“相同”分区的 UUID 不同?
UUID 代表通用唯一标识符。正如罐头上所说,它们的设计是普遍独特的。 UUID 是在创建时随机生成的,您必须采取某种肯定措施才能使它们相同。
至于什么会导致UUID改变呢?例如,文件系统格式化会导致它们发生变化。
所以是的,分区应该有不同的 UUID,这正是我们所期望的。
答案2
您检查过以下线程吗?
https://serverfault.com/questions/3132/how-do-i-find-the-uuid-of-a-filesystem 和
超级块存储这个32位十六进制ID,因此当超级块损坏时,uuid可能会发生变化。
答案3
我使用默认的 Ubuntu 16.04.06 ISO 进行了简化测试,甚至没有使用我在上面的 OP 中提到的自定义 Linux 磁盘映像。
待定;我确实看到即使配置相同,UUID 也会不断变化。所以并不是Linux操作系统的任何参数触发UUID改变。
从观察来看,@Livinglifeback 在之后的一条评论中说了些什么https://unix.stackexchange.com/a/580848/14968似乎是我所看到的合理解释:
图像将从文件系统获取,UUID 将在格式化时生成。如果您只是从映像克隆磁盘,那么磁盘将具有与其克隆的映像相同的 UUID。但图像没有理由彼此具有相同的 UUID。
我做的测试:
使用同一台计算机,从 .iso 安装 Ubuntu 16.04.06。然后sudo blkid
查看UUID /dev/sda2
。每次安装都选择完全相同的配置。
四分之四,我看到了不同的 UUID。