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 BA623138350 for ; Thu, 30 Apr 2020 20:21:21 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DE894E094E; Thu, 30 Apr 2020 20:21:16 +0000 (UTC) Received: from smtpcmd0641.aruba.it (smtpcmd0641.aruba.it [62.149.156.41]) by pigeon.gentoo.org (Postfix) with ESMTP id 3D1BEE085B for ; Thu, 30 Apr 2020 20:21:15 +0000 (UTC) Received: from mail.agr.fm ([151.48.153.140]) by smtpcmd06.ad.aruba.it with bizsmtp id Z8MF2200A320c1T018MF1n; Thu, 30 Apr 2020 22:21:15 +0200 Received: from [192.168.64.1] (fire.agr.fm [192.168.64.1]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.agr.fm (Postfix) with ESMTPS id B00E736001B for ; Thu, 30 Apr 2020 22:21:12 +0200 (CEST) Subject: Re: [gentoo-user] Trouble with backup harddisks 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> From: Andrea Conti Message-ID: <34ab0115-9336-ad41-5d30-7c8ce6ff1210@alyf.net> Date: Thu, 30 Apr 2020 22:21:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 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 In-Reply-To: <20200430192713.ptlo7crtwvskse7n@nabokov.fritz.box> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1588278075; bh=Pz1Nig6C0ahz6jSHHaeKz+joPMd0qJxKbsK9pQK/sug=; h=Subject:To:From:Date:MIME-Version:Content-Type; b=IcVfletWMEnBdIOD6Ty2Lev77zHI9Wsa0b5idaOoIobZnoNFRgJN7v1zijIUWJlqj 3KXWvQMDqL6T/DVsYtmaKLqgZKzTNnqmm4eiU1nHPE0drjtpXV/IIJH41GLgFYzPmY GLX9MivJ6u4cj1DeXWE1LIusdHWAAHIdJvxnqfl7uyQq9ccL3koAmpAk1sNPplSTj3 fwdya6svR92YFy/sAzkvlvuOfepUa4pbMUWVUCuwOm4PhqzCl90QsvdRdXdBLnnlCy 1ikWuz3Za8XqN3fOZOxHPhnNeqtmGRF0spm9rp56/O8cbmBHsbCEos2Jizs1CEGEN0 n4UvfoRd+pBKA== X-Archives-Salt: a99f0659-653b-4cf9-b8cf-a743dbc25f9a X-Archives-Hash: 674ba7a09ecb40526b931e113d324d1b > 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