1

On the same model of industrial PCs, I see UUID of the main SSD changed. Those 2 IPCs are restored from 2 similar but different Linux disk images. Question is as per the title. UUID of the main disk /dev/sda2 is different.

  • Both Ubuntu 16.04.
  • Linux disk image A: Kernel 4.15.0-65. UUID bc96e844-27c1-4ccb-af66-053cce7cecdb. User m, n exist. User n's home folder is encrypted.
  • Linux disk image B: Kernel 4.15.0-96 UUID 19e10365-d0b9-44c1-ac5d-a7acd5941bae. User m only exists. Some packages are newer.

Btw, we manufactured many IPCs with disk image A. While I haven't checked all IPCs, I just randomely checked some and they all show the same UUID.

On one host that was restored from image A, /var/log/syslog output this 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
:

(In fact, in the log above, I was doing some experiment so Kernel version was 4.15.0-58, not even 4.15.0-65, but the UUID is the same. So this Kernel version is ruled out)

On a host restored from the image B:

$ sudo blkid
:
/dev/sda2: UUID="19e10365-d0b9-44c1-ac5d-a7acd5941bae" TYPE="ext4" PARTUUID="d1cf8631-f3f7-4b8d-baba-86c6fcebe232"
:
1
  • You say one system has a different kernel than the others, and the others are the same? Is that different system the one with a newer kernel? If so, it's possible an OS update may be the reason
    – cutrightjm
    Commented Apr 18, 2020 at 3:41

3 Answers 3

0

Update:

Here's what's happening. The images are themselves copies of raw disks with partitions and filesystems. The disk layout, filesystems, contents and all will then be written to the disk on the computer you're imaging. At some point someone ran mkfs to create the filesystems used on the image and a UUID was generated. The images have different UUIDs from each other because they were generated from the contents of different filesystem. This makes sense because you'd normally do a clean install and thus repartition/reformat to generate the image.

This will only happen on image based installs, when you do a normal (install-root/debootstrap/pacstrap/etc/) install you'd typically reformat to delete old contents and thus generate a new UUID for the new filesystem.

Old:

I'm not 100% sure I understand the question but the way I'm parsing is: I have two of the same model of PC why are the UUIDs of the "same" partitions different?

UUID stands for Universal Unique Identifier. They are, as it says on the tin designed to be universally unique. The UUIDs are randomly generated at creation time and you'd have to take some kind of affirmative action to make them the same.

As for what would cause a UUID to change? filesystem formatting for example would cause them to change.

So yeah the partitions should have different UUIDs this is what we'd expect.

4
  • Sorry for confusion, but as I've updated my post to clarify, I see the same UUID on multiple different cells. So I can't agree with your conclusion "partitions should have different UUIDs".
    – IsaacS
    Commented Apr 18, 2020 at 3:29
  • If i'm understanding correctly, you're saying that the the UUIDs from image A are always the same and the UUIDs from image B are always the same, but that the UUIDs from A and B are different? Commented Apr 18, 2020 at 3:37
  • Assuming that's the case that makes sense. The images would be taken of filesystems and the UUIDs would be generated at format time. If you're just cloning the disks from the images then the disks would have the same UUIDs as the images they were clones from. But there would be no reason for the images to have the same UUIDs as eachother. Commented Apr 18, 2020 at 3:41
  • As I said in my unix.stackexchange.com/a/581044/14968, I guess what you're saying @Livinglifeback seems reasonable explanation. Would you mind 1) updating your answer to apply your latest answer in the comment, 2) elaborating what is "format time"?
    – IsaacS
    Commented Apr 19, 2020 at 6:30
0

Have you checked following thread.

https://serverfault.com/questions/3132/how-do-i-find-the-uuid-of-a-filesystem and

How to change filesystem UUID (2 same UUID)?.

Super block stores this 32bit hexID, so when super block gets corrupted, there may be a change in uuid.

0

I did simplified test using the default Ubuntu 16.04.06 ISO, without even using the custom Linux disk images I mentioned in my OP above.

TBDR; I do see UUID keeps changing even with the same configuration. So it's not any parameter of the Linux OS that triggers UUID to change.

From observation, what @Livinglifeback said in one of the comments after https://unix.stackexchange.com/a/580848/14968 seems to be the reasonable expalation for what I'm seeing:

The images would be taken of filesystems and the UUIDs would be generated at format time. If you're just cloning the disks from the images then the disks would have the same UUIDs as the images they were clones from. But there would be no reason for the images to have the same UUIDs as eachother.

The test I did:

Using the same 1 computer, installing Ubuntu 16.04.06 from .iso. Then sudo blkid to see UUID of /dev/sda2. Chose exactly the same configuration per each installation.

4 times out of 4, I saw the different UUID.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .