On 2026-08-08 17:50, David Wright wrote:
On Sat 08 Aug 2026 at 12:16:54 (-0400), Felix Miata wrote:
mick.crane composed on 2026-08-08 16:25 (UTC+0100):
> Device Start End Sectors Size Type
> /dev/sdb1 2048 2000895 1998848 976M EFI System
> /dev/sdb2 2000896 222339071 220338176 105.1G Linux filesystem
> /dev/sdb3 222339072 234440703 12101632 5.8G Linux swap
> The backup GPT table is corrupt, but the primary appears OK, so that
> will be used.
>
> ### (^^^^^^^ I always thought that this message was about the 111GB disk
> but now I think it is the fdisk reading first the partition/GPT table of
> the 2.73TB disk)
This is expected behavior from a true cloning, such as with dd or
ddrescue, from a
GPT disk to a larger GPT disk, since the backup partition table is at
the very end
of a GPT disk, and there isn't a valid one, or any at all, after such
a clone.
Whether any tool(s) exist in standard repos that can build a valid new
table
during its "cloning" process I have no idea. Given how long GPT has
existed, if
there isn't/aren't, it/they is/are long overdue.
NAME
gdisk - Interactive GUID partition table (GPT) manipulator
This was mentioned by the OP: "Perhaps I should have used gdisk
instead of fdisk …".
Using one of its expert menus (recovery and transformation options, or
extra functionality), there is this command available:
d use main GPT header (rebuilding backup)
(Be careful not to use its inverse.) But start by running and
understanding the output from gdisk -l device for each disk.
Cheers,
David.
Because the error message is immediately after the disk's partition list
and then there is a space before the next disk's partition list I
thought the message was about the list above it but it being about the
next disk makes more sense.
So the Linux OS disk is OK and it's the 2.7TB disk has wonky Backup GPT
Header
The other error message is about the clone having a Backup GPT Header in
the wrong place.
What I still don't know is if the Backup GPT Header can be on the end of
a partition or a special GPT part at the end of the disk outside the
primary partition.
In which case for the clone I should backup the primary GPT Table, then
extend the
OS partition somehow without overlapping the backup GPT header.
For the 2.7TB it is probably safer to sensibly prepare another ~3TB disk
and copy the files across.
Device Start End Sectors Size Type
/dev/sdb1 2048 2000895 1998848 976M EFI System
/dev/sdb2 2000896 222339071 220338176 105.1G Linux filesystem
/dev/sdb3 222339072 234440703 12101632 5.8G Linux swap
The backup GPT table is corrupt, but the primary appears OK, so that
will be used.
Disk /dev/sda: 2.73 TiB, 3000592982016 bytes, 5860533168 sectors
[..]
Device Start End Sectors Size Type
/dev/sda1 2048 5860532223 5860530176 2.7T Linux filesystem
GPT PMBR size mismatch (234441647 != 468862127) will be corrected by
write.
The backup GPT table is corrupt, but the primary appears OK, so that
will be used.
The backup GPT table is not on the end of the device.
Disk /dev/sdg: 223.57 GiB, 240057409536 bytes, 468862128 sectors
[..]
mick
