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.
