[SOLVED] UUIDs & PARTUUIDs

business_kid · 12-04-2021, 02:24 PM

I have been writing images for Arm boards to sdcards, a usb disk and even a 2.5" disk with dd. This is a recommended method. Partition 1 is vfat, partition 2 is ext4. But they are overwriting the UUID& PARTUUID, and copnsequently I have disks with the same uuid.

How does one change that? I would need to write different information, ideally without disturbing the contents.

wpeckham · 12-04-2021, 04:36 PM

Quote:

Originally Posted by business_kid

I have been writing images for Arm boards to sdcards, a usb disk and even a 2.5" disk with dd. This is a recommended method. Partition 1 is vfat, partition 2 is ext4. But they are overwriting the UUID& PARTUUID, and copnsequently I have disks with the same uuid.

How does one change that? I would need to write different information, ideally without disturbing the contents.

If two of those are never going to be mounted on the same machine at the same time it would not be fatal for them to use the same UUIDs. What is in your usage situation that requires them to be different?

syg00 · 12-04-2021, 05:05 PM

I can't believe a quick search wouldn't solve this immediately.
However, the point above is valid - I've never had a need to worry about it for my pi3s.

mrmazda · 12-05-2021, 05:01 AM

tune2fs -U random /dev/blah will change the UUID to some random value on EXTx filesystems. I'm not familiar with any FOSS tool capable of changing the PARTUUID, but there should be one, as the non-FOSS partitioner I use can do it (I believe, not something I've tried).

business_kid · 12-05-2021, 06:16 AM

Thank you, mrmazda, that will do nicely, I think. Partition 2 is a root drive, and partition 1 is mounted on a subdirectory of that root, /boot. The danger for me is that on an Arm box, I will have two drives with identical uuids, and raspbian uses uuids.

I can't imagine users of lesser OSes being trustred with a partition manipulating tool like that. I could get into the partition with a hex editor, search for the uuid/partuuid and insert random stuff, but I'll let at least one crash happen first. Or I could change partition 1 to ext4, fix the uuids, return to fat and restore a backup of the files

. That sounds lazier.

EDIT: Done it just now. Setting sdb2 sets the partuuid for all partitions, but the vfat uuid remains different.

computersavvy · 12-05-2021, 07:03 PM

Quote:

Originally Posted by business_kid

Thank you, mrmazda, that will do nicely, I think. Partition 2 is a root drive, and partition 1 is mounted on a subdirectory of that root, /boot. The danger for me is that on an Arm box, I will have two drives with identical uuids, and raspbian uses uuids.

I can't imagine users of lesser OSes being trustred with a partition manipulating tool like that. I could get into the partition with a hex editor, search for the uuid/partuuid and insert random stuff, but I'll let at least one crash happen first. Or I could change partition 1 to ext4, fix the uuids, return to fat and restore a backup of the files

. That sounds lazier.

EDIT: Done it just now. Setting sdb2 sets the partuuid for all partitions, but the vfat uuid remains different.

Almost every user can manipulate the UUID/GUID of a drive and its partitions. This from the man page for gdisk, expert menu

Code:

       c      Change partition GUID. You can enter a custom unique GUID for a partition using this option. (Note this refers  to
              the  GUID  that uniquely identifies a partition, not to its type code, which you can change with the 't' main-menu
              option.) Ordinarily, gdisk assigns this number randomly; however, you might want to adjust the number manually  if
              you've wound up with the same GUID on two partitions because of buggy GUID assignments (hopefully not in gdisk) or
              sheer incredible coincidence.


       f      Randomize the disk's GUID and all partitions' unique GUIDs (but not their partition type code GUIDs).  This  func‐
              tion may be used after cloning a disk with another utility in order to render all GUIDs once again unique.

I would recommend using gdisk, expert menu and the 'f' option on each device once the copy has been written to it. That changes the UUIDs for the device and partitions without affecting the data.

business_kid · 12-06-2021, 04:28 AM

What you suggested worked fine. Of course I have gdisk here, but I'll keep an eye on it if I dd over any more images. Will Gdisk handle vfat partitions formatted with fdisk?

mrmazda · 12-06-2021, 05:24 AM

I suggest to read gdisk's man page to see how or whether it "handles" what you wish "handled", and look up the definition of VFAT. Most partitioners are not also formatters. Gdisk and fdisk are not formatters. Gdisk doesn't care if your FAT type partitions' filesystems are format extended with VFAT, but does treat FAT partitions designated as ESP specially. Any "handling" gdisk does to an existing formatted partition will most likely destroy the filesystem on the partition. Gdisk does not care or know whether fdisk created an existing partition.

computersavvy · 12-06-2021, 10:53 AM

Note that gdisk with the options I suggested does not affect stored data in any way. All they do is change the UUID of the disk and partition and that info is in the partition table, not in the filesystem data. Those options do not alter the partitions themselves, just the related UUID, so any risk of data loss is negligible.

If you are concerned then try the commands on a spare disk or flash drive and see for yourself if there is reason to worry.

business_kid · 12-10-2021, 02:27 PM

As it turns out, this discussion was moot.

It transpired that a number of things chose that time to go dodgy or die. I'm also solving my UUID & PARTUUID issue. I disliked the chosen partition size so now I have been

dd installation image to usb key
rsync partition contents to their final resting places.
Storing backups by partition, eg boot, root & home.

framp · 12-10-2021, 03:18 PM

Keep in mind to update the old PARTUUID in /boot/cmdline.txt and /etc/fstab. Otherwise your system will not boot.

business_kid · 12-11-2021, 05:08 AM

Quote:

Originally Posted by framp

Keep in mind to update the old PARTUUID in /boot/cmdline.txt and /etc/fstab. Otherwise your system will not boot.

Thank you for putting this in print. I'm getting extremely used to systems not booting here, unfortunately. It's actually inclined to be systems picking up the initrd but not /lib/modules, or /. I lack the energy to sort those matters out atm. But I have one that works, and one is enough.