The last time I did something similar, I booted the PC with a Linux LiveCD that was customized to include a copy of GParted.
A new MBR and partition table was installed on the target drive (using GParted).
For each partition on the source drive:
Create a new partition on the target drive that is at least the same size as the original (using GParted or fdisk).
The closer you get to the exact number of sectors as the original the better, i.e. less chance of any issues with the transplanted filesystem.
Copy the partition from (or the partition image of) the original drive to the target drive using dd.
Resize the target partition to your new requirement (using GParted).
The filesystem within the partition will be adjusted commensurately.
Increasing the size should be rather quick.
Repeat for the next partition.
But Gparted has no option to make a partition hidden.
Your assertion is incorrect.
First select a partition.
Then from the menu bar, select
Partition, and choose
Manage Flags from the dropdown menu.
From there you can enable/disable an assortment of partition flags, including "hidden".
It also has no option to convert primary to logical ...
That is a questionable conversion that is best performed by basic operations.
A logical partition requires that it exists within an extended partition.
Automatically creating an extended partition does have ramifications, including available size and impact on subsequent operations.
Note the ability to create more than one extended partition depends on the tool and need to be portable. For Windows compatibility there can only be one extended partition.
... so if one copies an image onto a partition then wants to change a partition from primary to logical, they have to delete the partition and recreate it as logical and copy on again
The steps that I described above clearly state that the destination partition should be created prior to writing/copying the image.
If the target partition needs to be a logical partition, then first make sure there is already an extended partition, and then create the logical partition.
If you create a primary partition when the original was a logical partition, then you are simply botching the copy procedure.
Converting a primary partition to a logical partition is a bogus operation.
Suppose I don't know if the original was a primary or a logical, because e.g. the original hard drive is messed up.
So would you still say that if you create a primary instead of a logical then it's a botched copy procedure and therefore understandable that one has to copy again?
At what point and how did you determine that the destination partition should be a logical partition?
Given those answers, what is the reason why that determination could not have been available prior to creating the destination partition as a primary partition?
really the copy procedure is separate from creating partitions, and ...
Not in my procedure.
Each destination partition is created to its original size.
After the filesystem (i.e. the partition image) is written to the new partition, then it (the partition and filesystem) is resized.
This procedure relies on GParted knowing how to resize the filesystem contained within the partition.
I do not have to look-up/learn any filesystem commands on how to fit a filesystem to its partition. That task is assigned to GParted.
if there was an option to convert then one would not have to copy again –
The conversion from primary to logical partition is not as simple (or convenient) as you presume.
This web page describes a utility capable of "primary partition to logical partition" with just a mouse click or two.
The gotcha is revealed in this salient comment at the end of the article:
The location and the size of the primary partition will be slightly different after
converting due to the fact that the logical partition is 63 sectors bigger
than primary partition.
(That is poorly worded because it's hard to tell if the "63 sectors bigger" refers to the location or to the size of the logical partition (or both?). The change in "location" certainly makes sense. So I'm quite sure that if the writer was referring to the size, then he got the size difference backwards, otherwise that means that the conversion consumes more disk space than the original. There is simply no reason to increase the size of the resulting partition.)
Aside from the change(?) in partition size, the ramifications of this statement confirm that a time-consuming copy of the partition will occur.
The time to perform this copy will require about twice the time you could simply recreate the logical partition and write the image.
Why's that, you ask?
You start with a primary partition.
A logical partition has to be enveloped within an extended partition.
So the start of the original (primary) partition has to be pushed back to create space for the (start of the) new extended partition.
In theory just one sector could suffice, but the convention is one track, or the fake HDD geometry of 63 sectors.
In order to create this free space, the original (primary) partition (and its filesystem) first has to be reduced in size by 63 sectors at the end of the partition (assuming that this conversion consumes zero new disk space).
Then the original (primary) partition (and its filesystem) has to be moved back 63 sectors.
This move entails a time-consuming read and write of every sector of the partition.
Once the move is complete, the extended partition can be created in the newly freed area, and the original partition can be redefined as a logical partition.
This partition conversion procedure is not going to save you any time when you already have an image to write.
The only way to avoid the time-consuming copy during conversion would be to use a program that "cheats" and requires an unallocated track preceding the existing primary partition, such as this utility:
Note: ... there should be at least 63 free sectors in front of the primary partition
when changing it to logical.
also, you write "The closer you get to the exact number of sectors as the original the better, i.e. less chance of any issues with the transplanted filesystem." <-- can you elaborate on this?
That is simply my attempt to replicate the original partition.
There could be allocation round-off, and you cannot create the partition with the exact same number of sectors as the original partition (or size of the image).
So round up the number of sectors to the next allocation step.
As in if I don't get it close and then I resize it, what would that mean and what would happen?
would it mean that the resized partition will still remain a different size to the file system?
GParted has not complained when there is a small discrepancy between partition size and its filesystem.
After resizing by GParted, the filesystem seems to fully occupy the partition.
I have not experimented with the scenario you describe, so I don't have an answer.