Re: The backup GPT table is corrupt
Hi,
mick.crane wrote:
> 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?
Assumed that the target is /dev/sdb and it is at least as large
as the problem disk /dev/sda this would be
sudo dd bs=1M if=/dev/sda of=/dev/sdb status=progress oflag=dsync
sync
The dangerous part is the option of=... which names the target drive.
If you give the wrong address here, then you'd overwrite the wrong
disk.
The last two options are for realistic progress messages during the
copying.
Option bs=1M is used because the default bs=512 causes low throughput
(even without oflag=dsync).
The "sync" command is somewhat cargo cult. It will wait until the
operating system has indeed written all data from the i/o buffers to
the disk. Just in case oflag=dsync did not work as supposed.
After copying you will have to use gdisk (or alike) to move the
backup GPT to the end of the target disk. dd has put it to the same
block address as on the origin disk, which will probably be too low
because the target has not exactly the size of the origin disk.
(As said, the target disk may be larger but not smaller than the
origin disk.)
Booting should work already without that final gdisk run, because the
main GPT will be where it belongs: at block 1 and some following
blocks. So EFI BIOS will be able to find system partition with the boot
programs.
Maybe you will have to tell your other computer's EFI which program to
load from which partition. It should offer it among the boot choices.
In case of legacy booting: the MBR with the initial boot program code
will be in block 0 where legacy BIOS will look for it.
> I'll try the different entries in the BIOS and see if there is any
> difference.
The problem is on the first hand with the data in the last block of
your disk. So it is quite surely not with the BIOS and the boot
equipment on the disk.
The backup GPT might only come into play if the BIOS detects a damaged
main GPT and is brainful enough to try using the backup GPT in order
to find the EFI system partition (/dev/sda1).
The technical question is currently why the disk still shows a wrong
checksum although gdisk reported to have overwritten it.
I deem it improbable that gdisk computed and really wrote these four
bytes.
It seems slightly more probable that the disk silently did not take
the data which gdisk tried to write to it. (Normally gdisk should
have experienced an i/o error if writing did not work.)
> 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?
Dunno.
I would write a C program which uses open(2) with "/dev/sda",
lseek(2) with byte address 120034123776 - 512 + 16,
and write(2) with the four bytes {0x38, 0x1c, 0xd4, 0xe9},
which are supposed to be the right CRC for the backup GPT header.
I would test this program with a disk file instead of /dev/sda on a
filesystem which supports large sparse files (ext4 should do).
This should create a file of nominally 111+ GiB but of moderate disk
space consumption. (I have one named "100gb" with
107374182404 bytes shown by "ls -l 100gb" and 3176 KiB disk usage
shown by "du 100gb".)
For verification i would then check the nominal size, which should
be 120034123776 - 512 + 16 + 4 = 120034123284.
I would possibly waste CPU cycles by letting od show the octal address
01576245657020 in front of my four non-zero bytes.
When applied to the real disk, this should silence the gdisk warnings
... if the disk takes them and is willing to hand them out on read
requests.
sudo dd bs=512 count=1 if=/dev/sda skip=234441647 | \
od -t x1
should then show as second line:
0000020 38 1c d4 e9 00 00 00 00 af 4b f9 0d 00 00 00 00
instead of the previous
0000020 cc c9 67 f5 00 00 00 00 af 4b f9 0d 00 00 00 00
Have a nice day :)
Thomas
Reply to: