From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 259AF138350 for ; Thu, 30 Apr 2020 19:47:01 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 23400E09B6; Thu, 30 Apr 2020 19:46:54 +0000 (UTC) Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9CEFDE08DC for ; Thu, 30 Apr 2020 19:46:52 +0000 (UTC) Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 2D06B2400FC for ; Thu, 30 Apr 2020 21:46:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1588276011; bh=yiuyxfQQg4L5tYyf+5/gWWYmSnefTcwgYRaCoQlte3o=; h=Date:From:To:Subject:From; b=NjZGGcH87YMDX67cxw+9m3ol63aBbhnagwd5cJDnLsZE1NVkV0LMMwJmBWgc5SKzt STZxgOgp+OIuBAbZOfzH/t3JjHiTikY7hpwMJS/P9h/2Wn7W8k5GBzTLy2jNzvI2rc aOVbDVaFwTrNSCtC1xzfkCTiDKB5MwNEU1s0GjNhzHLU17nGMvIu8/qpHJxPmU2dea kIosMMDDxlz+OW6xJqOqztmoGLxJZCLOORRdDNvdsd49QBoxNrdnEOKuFbtiBmKkp1 v3eQ8dBDk/8LAninaMlkYD/X7PGA2fZEJEmFlZYYari07ttZ7f0gxZL7TxDaSlUCQv mmZjNBLSKkI7A== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 49Cm9Q4L7Zz6tmR for ; Thu, 30 Apr 2020 21:46:50 +0200 (CEST) Date: Thu, 30 Apr 2020 21:46:50 +0200 From: tuxic@posteo.de To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Trouble with backup harddisks Message-ID: <20200430194650.yjnmsuwwwq4j4eer@solfire> Mail-Followup-To: gentoo-user@lists.gentoo.org References: <20200430093217.efprkpt4kbvir7nr@solfire> <5EAAA0AB.3050505@youngman.org.uk> <22faa7cf-7291-b430-c646-b96c6d428f19@alyf.net> <20200430180839.iz4kxipst2i5stwp@solfire> <20200430192713.ptlo7crtwvskse7n@nabokov.fritz.box> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200430192713.ptlo7crtwvskse7n@nabokov.fritz.box> X-Archives-Salt: 37ce2442-3569-4e80-947e-7eff95238c67 X-Archives-Hash: 7b5e8618db7a4ad708c8360901c3cc33 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