> Since the disk was only ever accessed through an operating system that knew > solely about MBR, the GPT data meant nothing to it. It happily wrote data > past the MBR headers. Because the protective MBR is positioned before GPT > information, the primary GPT header was destroyed and most likely overwritten > with the file system. See also [1], the actual file system data probably > begins somewhere past LBA 0.
If it was created according to the MBR that was shown previously, it will start at the beginning of the protective entry, i.e. at sector 1. > If the initial assumption is correct, GPT *must not* be restored. Your modern > PC sees the GPT partition type and assumes the existence of a GPT. It should, > however, access the MBR layout and interpret the partition marked with the > GPT ID as a regular partition. It won't, as long as it recognizes it as a protective MBR. Which is the right thing to do, as a disk with a protective MBR and no valid GPT is inherently broken. > 1) Boot an older system that only understands MBR, and mount the disk there. > This was suggested earlier but was dismissed because we assumed the sector > size had something to do with it. I do not think this is the case anymore - > the old system should be able to read it. > > 2) Boot a VM with a kernel that only understands MBR, pass USB through to the > virtual machine, mount the disk there. > > 3) Try confirming that there exists file system data past the MBR header. > > Maybe something like this: > > # dd if=/dev/sdb of=sdb-data bs=512 skip=1 count=16384 > $ file sdb-data ... or just bypass the partition table altogether. The filesystem starts at sector 1, i.e. 1*512B, so: mount -o ro,offset=512 /dev/sdb /mnt/xxx But while this will allow you to access your data, you will still have a broken disk until you fix the MBR. andrea
