Re: cloning a disk

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.