Hi, mick.crane wrote: > I'm not understanding if the backup GPT Header is on the primary partition > or not.
See https://en.wikipedia.org/wiki/GUID_Partition_Table There is no primary partition with GPT, only a Primary GPT Header. At block 0 sits the Protective MBR which says "all is occupied, go away" to old partition editors. It also serves as indicator for the presence of the primary GPT header which is in block 1. Next comes the primary table of partition entries. In the last block of the storage device sits the backup GPT header with the backup partition entry table being stored before it. No partition is supposed to overlap with either of these headers and their tables. > I'm not knowing if after making the GPT table with fdisk then making 1 > primary partition on the 2.7TB disk I wrote over the GPT Backup Header. A proper gdisk run is supposed to write into both partition entry tables, and to update at least the checksums in both header blocks. Sorry i cannot tell why your fdisk runs sometimes report bad backup tables and sometimes don't. Especially riddling is this from an earlier post of you: 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. Neither the "all full"-size of the Protective MBR (PMBR) nor the other reported size matches the disk size. The PMBR should say size 0xffffffff to indicate that 5.8 billion does not fit into its 32 bit size field. The fact that the position field for the backup GPT header as stored in the primary GPT header does not match the last block address of the disk could indicate that the GPT was once copied from a smaller disk. But why then would it have that large partition ? Have a nice day :) Thomas
