On 2025-08-12 16:20, Thomas Schmitt wrote:
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.
1: I've got another PC and two of those StarTech USB things can attach
different disks to.
What's the incantation to copy this problem disk to another of similar
size and have it boot?
2: A decade ago I think I used some hex editor to change numbers on a
wireless dongle that apparently were what tied it to one provider. What
program to use to edit the backup GPT table?
I'll try the different entries in the BIOS and see if there is any
difference.
mick
