[CONFIGURATION] Clone an OS without including the source OS's partition table?

[RLynwood]

I'm not sure I got the right Prefix; I guess an administrator will move this post to the right one if I've got it wrong.

Is it possible to clone an OS (Mint 20 in this case) from my SSD to a back-up location temporarily without including the original OS's partition table? I want to keep the OS as is, i.e., all settings and personalizations, but I want it to be situated in GPT rather than the MBR it's in now.
I ask because it seems that changing the original partition table, MBR, to GPT is quite involved, making many opportunities for errors and even complete screw-ups.

[oshunluvr]

Clonezilla can clone a partition or a whole drive.

Partition tables can be copied, saved, and reinstalled, BUT GPT and MBR aren't the same (obviously).

Not sure what "quite involved" means in your world, but gdisk will convert MBR to GPT with one command. Not sure exactly how that impacts an Extended partition with Logical partitions as I can't recall trying it.

Of course, having a backup is mandatory before mucking about with a partition table.

Why not use clonezilla to clone the partition, take pic of your MBR partition table particulars (or save it to a thumb drive), and give gdisk a go?

Of course, if your Mint install is on a btrfs partition, you can clone it without Clonezilla.

[RLynwood]

Wow. Thanks. If a primary partition can be converted from MBR to GPT in one command, what is that? What could be easier or better than that? When I looked that up, the responses I got were a long string of commands, handling the conversion in a series of sections (don't know any better wording; sorry).

Mint is using ext4 in MBR, but I'd like to convert it to btrfs in GPT. In time, I'd like to learn how to clone my OSs that are in btrfs (I want both of them that way) without using Clonezilla.

[oshunluvr]

Tried this on a VM. Here's an MBR disk before conversion:

Device     Boot    Start      End  Sectors  Size Id Type
/dev/sdc1           2048  2097151  2095104 1023M 83 Linux
/dev/sdc2        2099200  4194303  2095104 1023M 83 Linux
/dev/sdc3        4196352  6291455  2095104 1023M 83 Linux
/dev/sdc4        6293504 20971519 14678016    7G  5 Extended
/dev/sdc5        6297600 12584959  6287360    3G 83 Linux
/dev/sdc6       12591104 20967423  8376320    4G 83 Linux
​​

After conversion to GPT:

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         2097151   1023.0 MiB  8300  Linux filesystem
   2         2099200         4194303   1023.0 MiB  8300  Linux filesystem
   3         4196352         6291455   1023.0 MiB  8300  Linux filesystem
   5         6297600        12584959   3.0 GiB     8300  Linux filesystem
   6        12591104        20967423   4.0 GiB     8300  Linux filesystem
​

Then I "sorted" the partitions:

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         2097151   1023.0 MiB  8300  Linux filesystem
   2         2099200         4194303   1023.0 MiB  8300  Linux filesystem
   3         4196352         6291455   1023.0 MiB  8300  Linux filesystem
   4         6297600        12584959   3.0 GiB     8300  Linux filesystem
   5        12591104        20967423   4.0 GiB     8300  Linux filesystem​

One odd thing I encountered was this message:
Warning! Secondary partition table overlaps the last partition by 33 blocks!

Apparently this is because GPT needs a little space at the end of the drive to store a backup partition table. I ended up shrinking the last partition by 1024b and it converted just fine after that.

[oshunluvr]

Gdisk does the partition table conversion automatically, so its:

sudo gdisk /dev/sdX
w

When you launch gdisk on an MBR drive, it creates a GPT partition table in memory but doesn't automatically write it to disk. The "w" issues the write command and exits gdisk.

If you launch gdisk and get the warning, you'll need to take care of that before it will let you save as GPT.

Here's from the wiki:

GPT writes its partition table to both ends of the disk, unlike MBR which only uses the beginning. So you will need to shrink your last partition by at least 33 blocks (probably 16,896 bytes, assuming 512 byte blocks). If you have or can install gparted, that makes it very easy to do.

[oshunluvr]

As far as EXT to BTRFS, the conversion still works but isn't officially supported any longer.

As ext4;

/dev/sdc1: UUID="372d5e58-efdd-4b25-a40e-26d8215f257a" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="00829e58-c7e5-477a-8167-aeaf67ad6cea"
/dev/sdc2: UUID="d06739ab-738f-468d-933e-5ca78d2b03e5" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="38b592d0-c39c-4b28-a3c9-5936097461c5"
/dev/sdc3: UUID="6602d5f7-6c3e-47a3-9f9e-dcb86d0e1691" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="e6553ed7-812f-43f8-a477-ae019a128638"
/dev/sdc4: UUID="d289309b-4cad-48c7-911b-f124748f3d18" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="de7f3941-9aea-432c-99b2-bccf7c79e83e"
/dev/sdc5: UUID="90b84648-15c9-4d7b-9e3b-b18695931288" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="73bce5b6-1b25-41f4-8cea-0bd3f6037749"
​

after conversion;

/dev/sdc1: UUID="d26e11dc-a57d-477b-b3a8-6aa2eea7c94d" UUID_SUB="ecc7e328-2306-4630-a796-782b51460637" BLOCK_SIZE="4096" TYPE="btrfs" PARTLABEL="Linux filesystem" PARTUUID="00829e58-c7e5-477a-8167-aeaf67ad6cea"
/dev/sdc2: UUID="226a4c83-93b9-4101-aa34-f85a81d77df1" UUID_SUB="3c6f407e-b6c7-4811-b6d8-60e45485fbb9" BLOCK_SIZE="4096" TYPE="btrfs" PARTLABEL="Linux filesystem" PARTUUID="38b592d0-c39c-4b28-a3c9-5936097461c5"
/dev/sdc3: UUID="bd429ecc-0afc-4a44-9880-cafda0b007c6" UUID_SUB="337ef8ed-995e-4533-b58a-639f8d6be17f" BLOCK_SIZE="4096" TYPE="btrfs" PARTLABEL="Linux filesystem" PARTUUID="e6553ed7-812f-43f8-a477-ae019a128638"
/dev/sdc4: UUID="68675e74-83d2-4739-8259-4abdd81ab279" UUID_SUB="ef03fd97-f18f-4b58-bdd0-4fdf1c39333a" BLOCK_SIZE="4096" TYPE="btrfs" PARTLABEL="Linux filesystem" PARTUUID="de7f3941-9aea-432c-99b2-bccf7c79e83e"
/dev/sdc5: UUID="2e5132c3-fb45-4d94-aecf-81bd8b8db7c3" UUID_SUB="43ccb042-f6f5-4df4-932c-b3b295279285" BLOCK_SIZE="4096" TYPE="btrfs" PARTLABEL="Linux filesystem" PARTUUID="73bce5b6-1b25-41f4-8cea-0bd3f6037749"
​​

[oshunluvr]

BTRFS will allow you to copy ("clone") a subvolume (how BTRFS separates space) to another btrfs file system or to a file. So making a "clone" or backup is as simple as issuing one command.

[RLynwood]

That all will take me some time to digest. I'll do that, then post again when ready. Thanks.