You have probably got this sorted out, but just in case you haven’t, you can easily change by randomizing the disk and partition UUIDs with sudo sgdisk -G <your-disk> while booted from a live iso and where <your-disk> is unmounted.
This will not change your partition type UUIDs just the unique UUIDs.
Good luck!
Problems solved.. I nuked the partitions on my old disk.. Rebooted without any issues… I then reinstalled the kernel-core and ran grub2-config to update everything and things are back on track. Well I learned something new from my mistake and at least will know what to do next time I clone a disk and leave the previous one in there, at least go in gparted and change the UUIDs.
Thanks to everyone that helped.
Yeah it is all sorted out now and noticed I can also change the UUID from gparted if I wanted to.. Thanks for the help!
Does that change the filesystem UUIDs though? That’s what’s relevant for /etc/fstab.
This guide is golden btw, clear steps to execute. I’m going to keep that somewhere safe in case I ever need to do this again. Thanks!
It changes the disk and partition unique GUIDs, which in my experience are the same as the UUIDs we’re referring to.
Here’s the section from the sgdisk man page:
-G, --randomize-guids
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 in order to render all GUIDs once again unique.
Partitions that are mounted in the filesystem retain their GUIDs.
I use disk and partition cloning as my backup method. When I do the former, I have to do this randomization thing so that I can mount partitions to recover files.
I do believe that there would be further work to do with /etc/fstab and the UEFI bootloader to coordinate the changes.
Just taking one partition as an example here:
Output of blkid:
/dev/nvme2n1p4: LABEL=“fedora” UUID=“b538ad6d-af9b-4609-b05e-5f1591d3195e” UUID_SUB=“975497db-5e10-479f-8a0d-a750167cc351” BLOCK_SIZE=“4096” TYPE=“btrfs” PARTUUID=“07d5caaf-f8a8-4f32-ac29-a70d1cb086de”
Corresponding /etc/fstab entry:
UUID=b538ad6d-af9b-4609-b05e-5f1591d3195e / btrfs subvol=root,compress=zstd:1 0 0
So /etc/fstab matches the UUID item from blkid. That’s the filesystem UUID.
Now, blkid also shows a PARTUUID - that’s the partition UUID and is different from the UUID. /etc/fstab (at least the way that the user here has it, and that Fedora sets it up by default) doesn’t use that ID. (The EFI boot manager entries do use that partition UUID as we saw upthread.)
From the docs of sgdisk, it seems clear that it changes the partition UUID. But does it definitely also change the filesystem UUID?
It changes both the disk and partition GUID/UUIDs. Isn’t the partition UUID is what’s being shown in both of your commands.
Correction: The UEFI bootloader would refer to the partition UUID for the EFI partition. I do not believe that either the sgdisk command or the UEFI bootloader know anything about filesystems. I could be wrong on that.
So in the output of blkid, each partition has both a UUID and PARTUUID.
I’m using the term “filesystem UUID” to refer to UUID, and the term “partition UUID” to refer to PARTUUID.
When you say “partition UUID”, do you mean the UUID rather than the PARTUUID?
It uses the PARTUUID. Per the example given upthread:
You can see there that the PARTUUID of “19002768…” shown in the blkid output is referenced in the EFI boot manager entry.
Thanks! Yes, I corrected that part in my post. Sorry for the faulty memory!
Yes, I should’ve written that.
I had this all sorted out at one time because I ran into it when I tried to recover backed up files from a LUKS encrypted disk. Clearly, my memory is not all that reliabile! 
I tested this in a VM:
sgdisk -G to randomise IDsThe result was that the UUID (the filesystem UUID, the one that matters for /etc/fstab) did not change. Only the PARTUUID changed.
pgtips@Rawhide-KDE-VM:~$ sudo blkid | grep /dev/vdb
/dev/vdb2: UUID="c15174ff-28f4-4c57-876a-07f5cbc0e814" BLOCK_SIZE="1024" TYPE="ext4" PARTUUID="3e1738b2-84b5-4ae9-855a-89d504a6ec1e"
/dev/vdb1: UUID="cfb9c5c8-3e9f-49b7-96a2-efe8cdd069e6" BLOCK_SIZE="1024" TYPE="ext4" PARTUUID="2d105629-0f6a-43da-92df-93275768aab2"
pgtips@Rawhide-KDE-VM:~$ sudo sgdisk -G /dev/vdb
The operation has completed successfully.
pgtips@Rawhide-KDE-VM:~$ sudo blkid | grep /dev/vdb
/dev/vdb2: UUID="c15174ff-28f4-4c57-876a-07f5cbc0e814" BLOCK_SIZE="1024" TYPE="ext4" PARTUUID="7b9b8378-998a-4895-927e-79985f105673"
/dev/vdb1: UUID="cfb9c5c8-3e9f-49b7-96a2-efe8cdd069e6" BLOCK_SIZE="1024" TYPE="ext4" PARTUUID="b6a6fb50-0967-4afa-86dc-0799ce477c27"
So this wouldn’t be enough to make the partitions “non-ambiguous” from the perspective of mounting them using /etc/fstab.
Interesting experiment!
But, now that I think about it, that makes sense. It is not uncomplicated, imo.
Thanks for straightening me out!
Indeed!
It’s possible to use PARTUUID instead of UUID in /etc/fstab entries, in which case using sgdisk -G should indeed take care of this “ambiguous mount” problem. In fact, that’s the way I have it set up on my Debian-based Raspberry Pi system.
Thanks for this info, too!
Like you, I’ve continued to look at some of the man pages for some of the related commands, like lsblk, and I’m beginning to think that the FS UUIDs are a UDEV-derived/generated identifier. I could be wrong on that one too, though.
The other conclusions I’ve come to is that: (1) It makes sense that sgdisk would only change the disk and partition GUIDs as that command doesn’t know anything about filesystems only the disks themselves; (2) The reason that all of this works for my purposes is that I do the mounts ad hoc; they don’t live across reboots, and there’s no need for, say, an fstab entry for a filesystem.
Thanks, again! This has been very educational.
As I understand it, the UUID is stored on the disk (in the filesystem metadata, I guess), but udev reads it and uses it to create pseudo-devices, and that udev mechanism is the way that many parts of the system “know” about the IDs.
Arch wiki says:
These identifiers are generated by filesystem utilities (e.g.
mkfs.*) when the device gets formatted and are designed so that collisions are unlikely. All GNU/Linux filesystems (including swap and LUKS headers of raw encrypted devices) support UUID. FAT, exFAT and NTFS filesystems do not support UUID, but are still listed in/dev/disk/by-uuid/with a shorter UID (unique identifier)
(Regarding FAT, I believe the filesystem doesn’t strictly speaking have a UUID, but it does have a serial number which behaves similarly, and serves as the UUID for many purposes - as we saw above in the command outputs for OP’s EFI partitions.)
I’m not sure what you mean by filesystem guid.. Are you referring to waht is in the /boot/efi?
GUID is Microsoft terminology. See https://en.wikipedia.org/wiki/Universally_unique_identifier. The Uses section has examples.
Taking one of your devices in the blkid output as an example:
/dev/nvme2n1p2: UUID=“97c7eb90-9bec-476c-83c1-997c3a836aab” BLOCK_SIZE=“4096” TYPE=“ext4” PARTUUID=“14544b8d-43dd-43bb-9a76-cd314d07a9ed”
UUID there is the filesystem UUID (stored in the filesystem’s metadata).
PARTUUID is the partition UUID (stored in the partition table).
Thanks now I know the difference!!