在同一型号的工业PC上,我看到主要SSD的UUID发生了变化。这两个IPC是从2个相似但不同的Linux磁盘映像中恢复的。问题是按照标题。主磁盘/dev/sda2
的UUID是不同的。
bc96e844-27c1-4ccb-af66-053cce7cecdb
.用户m,n存在。用户n的主文件夹是加密的。19e10365-d0b9-44c1-ac5d-a7acd5941bae
。用户m只存在。有些包是新的。顺便说一句,我们生产了许多带有磁盘映像A的个人电脑。虽然我还没有检查所有的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
:
(事实上,在上面的日志中,我做了一些实验,所以内核版本是4.15.0-58,甚至不是4.15.0-65,但是UUID是相同的。所以这个内核版本被排除在外了)
在从图像B恢复的主机上:
$ sudo blkid
:
/dev/sda2: UUID="19e10365-d0b9-44c1-ac5d-a7acd5941bae" TYPE="ext4" PARTUUID="d1cf8631-f3f7-4b8d-baba-86c6fcebe232"
:
发布于 2020-04-18 03:07:54
更新:
这是正在发生的事情。映像本身就是带有分区和文件系统的原始磁盘的副本。然后,磁盘布局、文件系统、内容和所有内容都将写入您正在映像的计算机上的磁盘。在某个时候,有人运行mkfs来创建映像上使用的文件系统,并生成了一个UUID。这些映像具有不同的UUID,因为它们是从不同文件系统的内容生成的。这是有意义的,因为您通常会进行干净的安装,从而重新分区/重新格式化以生成映像。
这只会发生在基于映像的安装上,当您执行普通安装( install -root/debootstrap/pacstrap/etc/)安装时,通常会重新格式化以删除旧内容,从而为新的文件系统生成一个新的UUID。
旧:
我不是100%肯定我理解这个问题,但我解析的方式是:我有两个相同型号的PC,为什么“相同”分区的UUID不同?
UUID代表通用唯一标识符。正如上面所说的那样,它们是设计成普遍独特的。UUID是在创建时随机生成的,您必须采取某种肯定措施使它们保持不变。
至于什么会导致UUID改变呢?例如,文件系统格式化会导致文件系统更改。
所以,是的,分区应该有不同的UUID,这正是我们所期望的。
发布于 2020-04-18 04:50:02
您是否检查了下面的线程。
https://serverfault.com/questions/3132/how-do-i-find-the-uuid-of-a-filesystem和
超级块存储这个32位的hexID,所以当超级块被破坏时,uuid可能会发生变化。
发布于 2020-04-19 06:28:53
我使用默认的Ubuntu16.04.06 ISO进行了简化测试,甚至没有使用我在上面的操作中提到的自定义Linux磁盘映像。
我确实看到UUID在相同的配置下也在不断变化。因此,触发UUID更改的不是Linux操作系统的任何参数。
从观察来看,@Livinglifeback在https://unix.stackexchange.com/a/580848/14968之后的一条评论中说的,似乎是对我所看到的东西的合理扩展:
这些映像将用于文件系统,UUID将在格式化时生成。如果您只是从映像中克隆磁盘,那么磁盘的UUID将与它们所克隆的映像相同。但是,这些映像没有理由具有相同的UUID。
使用同一台计算机,从.iso安装Ubuntu16.04.06。然后sudo blkid
来查看/dev/sda2
的UUID。每个安装都选择完全相同的配置。
4次,我看到了不同的UUID。
https://unix.stackexchange.com/questions/580846
复制相似问题