Re: [gentoo-user] Trouble with backup harddisks

[tuxic@posteo.de]

Hi Wolf,

thanks for your great input again!

(see below)

On 04/30 09:27, Wynn Wolf Arbor wrote:
> All the following assuming that the disk was originally partitioned as GPT,
> but after that exclusively accessed as an MBR disk.
> 
> > PT fdisk (gdisk) version 1.0.5
> > 
> > Caution: invalid main GPT header, but valid backup; regenerating main header
> > from backup!
> 
> This makes sense since the GPT backup at the very end of the disk would most
> likely still be intact. gdisk identifies it correctly, but assumes (wrongly)
> that the data on the disk is governed by the GPT layout.
> 
> 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.
> 
> > Caution! After loading partitions, the CRC doesn't check out!
> > Warning: Invalid CRC on main header data; loaded backup partition table.
> > Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
> > on the recovery & transformation menu to examine the two tables.
> 
> This is because the backup GPT written when first partitioned does no longer
> match the data present at the very beginning of the disk.
> 
> 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.
> 
> Now, how to fix this?
> 
> Like Andrea already said earlier:
> 
> > Since the disk is only 1TB, there is no reason to use GPT at all, so
> > your best bet is to use fdisk to make that a standard MBR by changing
> > the partition type from 'ee' to '83'.
> 
> This would *not* repartition or reformat any data, it would simply tell your
> modern operating system to access the protective partition as a regular one.
> 
> It would, however, require writing the new type to disk. What you could do
> to be more safe here is to take a backup of the first 512 bytes with `dd',
> then change the partition ID with `fdisk', and try mounting it.
> 
> If it works, great. If not, you can restore the first 512 bytes of the disk
> with the backup.
> 
> > "fix manually" scares me...especially because I have no place for
> > 1TB of an image file to with which I can experiment ...
> 
> > Any ideas which could ease my burden and to un-scare my
> > "need to fix it manually" ??? ;) ;)
> 
> There's a few alternatives:
> 
> 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
> 
> As established, the block size is 512 bytes. We skip the first 512 bytes
> since that is the protective MBR. sdb-data should then contain the first
> 8MiB worth of actual file system data. The `file' utility can tell you what
> kind of data it is.
> 
> [1] https://en.wikipedia.org/wiki/GUID_Partition_Table#/media/File:GUID_Partition_Table_Scheme.svg
> 
> -- 
> Wolf
> 

I had booted into my old system, attached the disks and both show the
same behaviour: Only the device itself (/dev/sdb) was recognized.

'file' shows the following output:

file sdb-data
sdb-data: Linux rev 1.0 ext4 filesystem data, UUID=2f063705-0d3a-4790-9203-1b4edab7788c (extents) (64bit) (large files) (huge files)

Looks better than I have thought...or?

I will take a deeper look tommorrow...I am too tired to
"fix partition tables manually" this evening!

Read you tommorrow! :)

Cheers!
Meino