Re: The backup GPT table is corrupt
Hi,
mick.crane wrote:
> 0000000 45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00
> 0000020 cc c9 67 f5 00 00 00 00 af 4b f9 0d 00 00 00 00
> 0000040 01 00 00 00 00 00 00 00 22 00 00 00 00 00 00 00
> 0000060 8e 4b f9 0d 00 00 00 00 b6 c0 c0 ce 33 a9 6a 42
> 0000100 92 1b 04 bd a9 9e 80 8b 8f 4b f9 0d 00 00 00 00
> 0000120 80 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00
> 0000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
The CRC "cc c9 67 f5" is indeed wrong. It should be "38 1c d4 e9".
I am quite sure that gdisk can compute the right checksum.
So the riddle is why it did not write it into the last block of the
disk.
Experiment proposal if you have really strong nerves:
You could alter these 4 bytes to e.g. "00 00 00 00" on the disk and
verify that gdisk does not write the bytes "cc c9 67 f5" during a new
attempt to repair the block.
But i am not sure whether i'd dare this dangerous manual intervention,
given that your main block is ok and the backup block woes don't hamper
the use of your disk.
gdisk even confirmed that the partition entries of the backup table
are ok:
> Backup header: ERROR
> Backup partition table: OK
So it will probably be usable if you ever need it.
-----------------------------------------------------------------------
Long story:
The block begins by "EFI PART" which is the magic number of a GPT
header block. So most probably it is indeed the right block.
I converted this back to binary and checked by "od -t x1" and "diff"
that the converted binary data yield the same hex numbers as the
hex dump in your mail.
Then i set the four bytes at offsets 16 to 19 to value 0 as prescribed
by the GPT specs and truncated the binary data to 92 bytes which is
the CRC's range according to GPT specs.
cksum(1) prints
2048104003 92
which by
printf '%x\n' 2048104003
yields
7a139643
As little endian hex bytes this is
43 96 13 7a
But as it seems this CRC variant is not what GPT means to be used.
So i made a standalone version of iso_crc32_gpt() from libisofs.
This yields
38 1c d4 e9
which does not match the hex representation in gpt_backup_header.hex
cc c9 67 f5
either.
In order to check my procedure, i re-computed the checksums of main GPT
header block and backup GPT header block of a grub-mkrescue ISO.
It has a pure GPT which is recognizable by partition editors.
gdisk of Debian 12 has no complaints about its CRC:
$ /sbin/gdisk grub-mkrescue-original.iso
GPT fdisk (gdisk) version 1.0.9
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): v
Warning: There is a gap between the main metadata (sector 1) and the main
partition table (sector 20). This is helpful in some exotic configurations,
but is generally ill-advised. Using 'j' on the experts' menu can adjust this
gap.
No problems found. 3 free sectors (1.5 KiB) available in 1
segments, the largest of which is 3 (1.5 KiB) in size.
Debian 12 and 13 obviously use the same version of gdisk.
My re-computed checksum bytes match the ones which i see in the GPT
header blocks of the ISO image. So to my best effort, gdisk confirms
the validity of the checksums in the ISO (originally from libisofs)
and thus from my re-computation.
(The complained gap results from a little stunt of grub-mrescue
and libisofs which squeezes an Apple Partition Map between main GPT
header block and the array of GPT partition entries.
It is less of a jackalope than a Debian netinst ISO, nevertheless.)
Have a nice day :)
Thomas
Reply to: