How to change GUIDs on a cloned drive?

As part of my work, I need to clone openSUSE drives and then modify them. Cloning is easy with Clonezilla, but the cloned drives end up with the same disk and partition GUIDs, which causes boot and partition mounting trouble (see my previous question Understanding UEFI boot drives, and how UEFI chooses which drive to boot from ).

In responses to that question, arvidjaar suggested:

From man gdisk, the expert f option:

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

So, that’s a start, but it isn’t sufficient, as it will render the drive unbootable, as /etc/fstab’s drive references will be wrong, and there many be other places where the GUIDs are referenced.

So, how can I take a bootable drive and randomize its GUIDs (drive and partition), and have it still be bootable? Would hand-editing /etc/fstab be sufficient?

Any config file that refers to UUIDs needs to be changed. In addition to fstab that includes grub.cfg at the least, and possibly /etc/default/grub.

As a heavy user of cloning, my fstabs and bootloader configs prefer LABELs to UUID everythere it’s an option. My dependence on grub.cfg is limited to its ability to load /boot/grub2/custom.cfg, where no UUIDs are present, and which is responsible for the first Grub menu selections displayed on boot. Considerably shorter LABELs make required hand editing typos easier to avoid.

1 Like

Isn’t that the source of your trouble? You blame “your work”, which is rather abstract. But “your work” probably wants to achieve a goal where cloning is not a good solution.

By cloning a whole disk (mass-storage device) the partition UUIDs (as in /dev/disk/by-partuuid), the file system UUIDs (as in /dev/disk/by-uuid), the partition labels (as in /dev/disk/by-partlabel) and the volume labels (as in /dev/disk/by-label) are all copied. After the cloning one should asap remove one of the disks from the system ad take care that the two never are connected to the same system at the same time. That is the nature of it. Trying to fool this principle will be a hard task I assume.

1 Like

I’m updating an existing product that was based on openSUSE 12.3. Back then, we had a workflow centered on cloning that worked well, supported by a number of custom tools. Switching to openSUSE 15.5 broke this, probably because openSUSE switched to using GUIDs.

So, I’m hoping to preserve our workflow. I would appreciate any suggestions you may have (e.g. as offered by mrmazda), but just saying “do something else” isn’t all that useful.

GRUB does not even support partition GUID.

openSUSE does use the uuid of the file system, not those of the GPT partitions. This to make clear without doubt what the subject is. Before it used the device files (/dev/sdXN), you can still do hat.

Od course I can not be more recise. Your

does not provide much information to work on for suggestions.

As installed by the openSUSE installer, there are lots of UUIDs in /etc/fstab:

UUID=bbc738d1-eb16-46a4-8335-9580a87c5b3d  /                       btrfs  defaults                      0  0
UUID=bbc738d1-eb16-46a4-8335-9580a87c5b3d  /var                    btrfs  subvol=/@/var                 0  0
UUID=bbc738d1-eb16-46a4-8335-9580a87c5b3d  /usr/local              btrfs  subvol=/@/usr/local           0  0
UUID=bbc738d1-eb16-46a4-8335-9580a87c5b3d  /tmp                    btrfs  subvol=/@/tmp                 0  0
UUID=bbc738d1-eb16-46a4-8335-9580a87c5b3d  /srv                    btrfs  subvol=/@/srv                 0  0
UUID=bbc738d1-eb16-46a4-8335-9580a87c5b3d  /root                   btrfs  subvol=/@/root                0  0
UUID=bbc738d1-eb16-46a4-8335-9580a87c5b3d  /opt                    btrfs  subvol=/@/opt                 0  0
UUID=bbc738d1-eb16-46a4-8335-9580a87c5b3d  /home                   btrfs  subvol=/@/home                0  0
UUID=bbc738d1-eb16-46a4-8335-9580a87c5b3d  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
UUID=bbc738d1-eb16-46a4-8335-9580a87c5b3d  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
UUID=9C8B-F18F                             /boot/efi               vfat   utf8                          0  2
UUID=2e8e317c-cf0b-47ed-bd2b-0c30c340fb6d  swap                    swap   defaults                      0  0
UUID=bbc738d1-eb16-46a4-8335-9580a87c5b3d  /.snapshots             btrfs  subvol=/@/.snapshots          0  0

My /boot/grub2/grub.cfg contains eighteen references to my root partition’s UUID bbc738d1-eb16-46a4-8335-9580a87c5b3d, e.g.:

menuentry 'openSUSE Leap 15.5'  --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-bbc738d1-eb16-46a4-8335-9580a87c5b3d' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_gpt
	insmod btrfs
	search --no-floppy --fs-uuid --set=root bbc738d1-eb16-46a4-8335-9580a87c5b3d
	echo	'Loading Linux 5.14.21-150500.55.83-default ...'
	linux	/boot/vmlinuz-5.14.21-150500.55.83-default root=UUID=bbc738d1-eb16-46a4-8335-9580a87c5b3d  ${extra_cmdline} splash=silent preempt=full quiet security=apparmor mitigations=off
	echo	'Loading initial ramdisk ...'
	initrd	/boot/initrd-5.14.21-150500.55.83-default
}

AFAICT, that’s the only UUID being referenced in /boot/grub2/grub.cfg, which makes sense; once you mount the boot partition you can access /etc/fstab and work from there.

My /etc/default/grub has no UUIDs or other disk/drive identifiers.

Assuming you’re using GUID as synonymous with UUID, there are lots of UUIDs in my /boot/grub2/grub.cfg (see above).

OK, after doing more research and experimentation, I’ve found that gdisk x f does change the disk identifier GUID. Specifically, the “Disk identifier GUID” reported by gdisk /dev/sda always matches the “PTUUID” reported by blkid /dev/sda, and running gdisk x f changes that value. Once changed, it allows a cloned drive to be distinguished by UEFI (see Understanding UEFI boot drives, and how UEFI chooses which drive to boot from ), and that’s helpful.

But, gdisk does NOT seem to change partition UUIDs, but perhaps that’s because there each partition actually has multiple UUIDs. For instance:

devuser@product:~> lsblk -f /dev/sda
NAME   FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                           
├─sda1 vfat   FAT32       DF1E-A37D                                           
├─sda2 btrfs              de596190-79c1-467a-8998-d00f0d630740   46.5G    11% /mnt/tmp
└─sda3 swap   1           17a16f0d-b6fd-4c89-ac04-b4f0e8324ccd                
devuser@product:~> sudo gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): i
Partition number (1-3): 1
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI system partition)
Partition unique GUID: 2CDD1892-D9DC-411F-BBBB-3FFD02B23688
First sector: 2048 (at 1024.0 KiB)
Last sector: 1050623 (at 513.0 MiB)
Partition size: 1048576 sectors (512.0 MiB)
Attribute flags: 0000000000000000
Partition name: ''

Command (? for help): i
Partition number (1-3): 2
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: F1261C1A-6061-42C8-86FA-CE866F9D92C8
First sector: 1050624 (at 513.0 MiB)
Last sector: 113035263 (at 53.9 GiB)
Partition size: 111984640 sectors (53.4 GiB)
Attribute flags: 0000000000000000
Partition name: ''

Command (? for help): i
Partition number (1-3): 3
Partition GUID code: 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F (Linux swap)
Partition unique GUID: B5116F65-74FF-4A00-BF20-2E3546722B55
First sector: 113035264 (at 53.9 GiB)
Last sector: 117231374 (at 55.9 GiB)
Partition size: 4196111 sectors (2.0 GiB)
Attribute flags: 0000000000000000
Partition name: ''

Command (? for help): x

Expert command (? for help): f

Expert command (? for help): i
Partition number (1-3): 1
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI system partition)
Partition unique GUID: CF93EB29-270C-48E9-873A-7DBD5021CBE5
First sector: 2048 (at 1024.0 KiB)
Last sector: 1050623 (at 513.0 MiB)
Partition size: 1048576 sectors (512.0 MiB)
Attribute flags: 0000000000000000
Partition name: ''

Expert command (? for help): i
Partition number (1-3): 2
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: E3D912FF-1191-4266-939D-8CC0E192B966
First sector: 1050624 (at 513.0 MiB)
Last sector: 113035263 (at 53.9 GiB)
Partition size: 111984640 sectors (53.4 GiB)
Attribute flags: 0000000000000000
Partition name: ''

Expert command (? for help): i
Partition number (1-3): 3
Partition GUID code: 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F (Linux swap)
Partition unique GUID: A98682F2-AD0C-47D8-8447-882CAE0050CC
First sector: 113035264 (at 53.9 GiB)
Last sector: 117231374 (at 55.9 GiB)
Partition size: 4196111 sectors (2.0 GiB)
Attribute flags: 0000000000000000
Partition name: ''

Expert command (? for help): q
devuser@product:~> lsblk -f /dev/sda
NAME   FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                           
├─sda1 vfat   FAT32       DF1E-A37D                                           
├─sda2 btrfs              de596190-79c1-467a-8998-d00f0d630740   46.5G    11% /mnt/tmp
└─sda3 swap   1           17a16f0d-b6fd-4c89-ac04-b4f0e8324ccd
devuser@product:~> 

So, gdisk x f changes what it calls “Partition unique GUID”, but it doesn’t change what it calls “Partition GUID code”, and doesn’t change the UUID reported by lsblk (and used by fstab and grub.cfg).

Is this the difference between a “filesystem UUID” and a “partition UUID”? If so, then perhaps I want to change the “filesystem UUID” of the partitions? And I’ll need another tool.

From linux - How to change filesystem UUID (2 same UUID)? - Unix & Linux Stack Exchange, that tool would be file system specific. For the btrfs partition, perhaps I need to use `btrfstune -U [UUID] /dev/sda2? (And, since I probably don’t need to mount the EFI or swap partitions, maybe that’s enough.)

Good clarification: thanks.

More info: blkid /dev/sda2 reports three UUIDs:

devuser@product:~> sudo blkid /dev/sda2
/dev/sda2: UUID="de596190-79c1-467a-8998-d00f0d630740" UUID_SUB="719fee13-7b01-45c9-bebf-ab615e186303" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="f1261c1a-6061-42c8-86fa-ce866f9d92c8"
devuser@voltair-new:~> lsblk -f /dev/sda2
NAME FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda2 btrfs              de596190-79c1-467a-8998-d00f0d630740                
devuser@product:~> 

The UUID value matches the value used by fstab and grub.cfg. The PARTUUID value matches the “Partition unique GUID” reported by gdisk i. And I have no idea what UUID_SUB is.

(Boy, would standard terminology be helpful…)

I think your terminology is a bit confused.

The UUID typically used in “fstab” is the “file system UUID” which is not the same as the “Partition UUID”.

When I run “blkid” it reports UUID (which is the file system UUID) and it reports PARTUUID (the partition UUID). I would expect “gdisk” to change the partition UUID but not the filesystem UUID.

To change the file system UUID, you will need the appropriate filesystem command.

I tihnk the GUIDs, the configs that they’re used in, are not even half your problem. Relying on an OS for so many years will result in a situation where any update can break a system. You’re deploying disks, this smells like there are better solutions now, containerization ? I guess “work” is “job”, get your issue, been there, done that etc.

And with btrfs you are still left with duplicated device UUID (I am not aware of any way to change that).

btrfs seeding device may be more safe way to clone it.

Good point. I hadn’t said in this thread, but this is an embedded hardware product, and nobody will be logging into the system, which reduces (although it does not eliminate) the need for system updates. When one is necessary, we will review our options.

Just jumping into this conversation, to give my two cents. I just checked to be sure but GParted >partition has the function of “new UUID” . . . and I might have used that in one of my past problems when either OSX or one of the Ubuntu installs took over the grub function and wiped out the UUIDs . . . .

Or, I might have simply manually edited the /etc/fstab directory and manually typed in the UUID number that was in lsblk -f to get them matching??? It’s not super hard to get the UUIDs to match across the grub, fstab, and blkid?? (or whatever) . . . . If I can do it, anybody can.

This is informative, I thought the OP wanted to change their cloned drives descriptor in some way though.

1 Like

BTW: I have a solution, but don’t have time to write it up at the moment. Summary for now:

  • Use gdisk to randomize the target drive’s UUID, so that UEFI can select the proper boot drive
  • Get the target drive’s root partition’s file system UUID
  • Use btrfstune to randomize the root partition’s file system UUID
  • In the target drive’s /etc/fstab, fix all references to the root partition’s file system UUID
  • Using chroot to the target drive, run grub2-mkconfig to rebuild both copies of grub.cfg

But, the devil’s in the details, so I’ll write it up completely.

Thanks for all the help,
Dan

Where is the second copy? Or maybe I should ask, where is the first copy?

One is /boot/grub2/grub.cfg, the other is /boot/efi/EFI/opensuse/grub.cfg. Note that these are on different partitions for the default install. (Testing shows the second is definitely being used; I rebuilt the first just in case.)