LVM and all the other stuff like PVM etc

The point here is to make use of a cloned disk / SSD. Linux will complain if one clones a disk / SSD because UUIDs are the same, so understandable. What to do?

Change the UUIDs? Arggg! Like so many things with Linux everyone has an opinion. I just love the people that say to, "...just wipe the 'offending' disk and start over." WTF?!?!? Really, that's your solution? Then what's the point of the clone? Why not just never do the clone, that way one doesn't have to do any wiping. Oh, yeah, there's a reason the clone was done in the first place moron.

Anyway, tons of commands for PVGs, LVMs, etc. See below;

PVG (Physical Volume Group)

Why not something better? Hmmm, what about this: vgimportclone (https://man7.org/linux/man-pages/man8/vgimportclone.8.html) and explained by: https://kerneltalks.com/howto/how-to-import-vg-using-different-vg-name/

Example: vgimportclone -n WhatEverNewNameForClonedDisk /dev/sdX (where sdX is the duplicate disk / SSD, UUIDs are generated automatically)

Oh, wait, not done yet. A small exception, because I have found the need to adjust / change disks months and years later from MBR / BIOS to GPT / UEFI and back the other way too. So that means, in preparation for that change, there needs to be a small section of the disk to store MBR information on a UEFI disk / SSD. In Linux, this seems to be BOOTBIOS (PS, it appears to be a really big secret, so there isn't much information about it, so thanks to a hint from https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Disks#What_is_the_BIOS_boot_partition.3F which quickly lead to https://en.wikipedia.org/wiki/BIOS_boot_partition for a nice explanation).

TUNE2FS? Nope, that's only for ExtX File Systems.

GDISK or FDISK using the "x" (expert command) to change the GUID, sort of, GDISK seems to be for GPT disks, not MBR disks, where as FDISK seems oriented towards MBR Disks, so...

To change the Disk Identifier;

  • fdisk /dev/sdX (where sdX s the disk / SSD to be modified)
    • Type the following (but not what's in the parenthesis);
      • x (for expert mode)
      • i (change the Disk Identifier)
      • Type the new ID starting with 0x (to identify it as a Hexadecimal Number, $ in the Commodore days) and 8 digits in length (which works out to 4 Bytes), for example: 0x12345678
      • r (return to 'non-expert' menu)
      • w (write the changes to the disk)
      • Thank you: https://forums.raspberrypi.com/viewtopic.php?t=191775


And of course if there are any EXT4 (EXT2, EXT3 formatted Partitions) that need a new UUID;

tune2fs -U random /dev/sdX

Instead of using individual mount commands for temporarily mounting a device, edit the freaking /etc/fstab file and run this command to mount or remount everything in the /etc/fstab file: mount -av

OK, how about renaming Logical Volumes and Logical Volume Groups?

...oh, and I cannot begin to describe how many different websites there are that provide information about various commands (lsblk, blkid), all very useful, but don't cover this one: SSM (Storage System Manager, for Fedora, CentOS, Rocky Linux, etc.) There's actual useful information here about Logical Volumes, DEVICEs and their mount points, etc. Try this: ssm list (WOW! Cool!)

Some Interesting References

Exporting and Importing Volume Groups: https://tldp.org/HOWTO/LVM-HOWTO/recipemovevgtonewsys.html

LVSCAN: Command for showing the Logical Volumes available and whether they are active or inactive.

LVRENAME: lvrename /dev/rl/swap-0 /dev/rl/swap

Swap File

...from: https://www.computernetworkingnotes.com/linux-tutorials/how-to-create-swap-partition-in-linux.html OR use the blivet-gui from Red Hat OR better than the blivet-gui, use the Cockpit Web GUI

And from there, make sure to 'turn on' the SWAP Partition: swapon /dev/rl/swap (plus the 'partition', in this case an LVM partition, needs to be mounted, and is best done in fstab to be persistent)

Setting or Changing UUIDs for a Cloned Disk / Drive with Various Partition Types and File Systems

  • BIOSBOOT
    • First take a look at the other Disk Identifiers
      • fdisk -l /dev/WhatEverOtherDiskOrDrive / fdisk -l /dev/sda
    • fdisk /dev/sdX (where sdX s the disk / SSD to be modified)
      • Type the following (but not what's in the parenthesis);
        • x (for expert mode)
        • i (change the Disk Identifier)
        • Type the new ID starting with 0x (to identify it as a Hexadecimal Number, $ in the Commodore days) and 8 digits in length (which works out to 4 Bytes), for example: 0x12345678
        • r (return to 'non-expert' menu)
        • w (write the changes to the disk)
        • Thank you: https://forums.raspberrypi.com/viewtopic.php?t=191775
  • 83 / EXT4
    • tune2fs -U random /dev/WhatEverDevice / tune2fs -U random /dev/sdd2
    • ...but first e2fsck -f /dev/WhatEverDevice / e2fsck -f /dev/sdd2 (because the tune2fs command will complain with this error: "This operation requires a freshly checked filesystem. Please run e2fsck -f on the filesystem.")
  • LVM
    • vgimportclone /dev/WhatEverDevice(Partition) / vgimportclone /dev/sdd3 (seems to implicitly change UUID of Volume Group with vgchange AND also the UUID of the underlying physical partition, IE /dev/ssd3, so two UUIDs, if not more, seem to get changed with vgimportclone)
      • This subsection is just FYI, doesn't need to be done as it would simply repeat what the vgimportclone command implicitly does;
        • vgchange --uuid /dev/rl
        • ...but first the Logical Volumes must not be active
          • Display Active Logical Volumes: lvscan
          • Deactivate Logical Volume: lvchange -a n /dev/rl1/root
    • pvchange --uuid /dev/sdd3
    • And for changing the Logical Volume UUID, well, according to the below, it can't be done (but good news, it doesn't appear it needs to be done);
      • Explained briefly here: https://unix.stackexchange.com/questions/724831/how-to-change-logical-volume-uuid
      • A more in depth explanation is here: https://bugzilla.redhat.com/show_bug.cgi?id=979720
      • Doesn't need to be done? WTF?;
        • Well, unlike other things that get mounted in /etc/fstab/ Logical Volumes don't need to use UUIDs (they can though), and it doesn't get all messed up if drives are changed around like with regular SDA, SDB, etc. assignments, as the Logical Volume Manager keeps track of things (yup scary, but it seems to work)
        • And it seems the true Logical Volume UUID is comprised of the Physical Volume UUID and Logical Volume UUID, so as long as the Logical Volumes with the same UUID aren't in the same Volume Group, no issues.
    • To 'activate' the Logical Volume: lvchange -a y /dev/rl1/root (deactivate changes the 'y' to an 'n': lvchange -a n /dev/rl1/root )
    • NOTES;
      • lvscan: shows which volumes are active
      • blkid: shows UUIDs in order to verify change