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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)