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 DD383138350 for ; Thu, 30 Apr 2020 17:05:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 751ADE088A; Thu, 30 Apr 2020 17:04:57 +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 E6BAAE0839 for ; Thu, 30 Apr 2020 17:04:56 +0000 (UTC) Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id C61E12400FE for ; Thu, 30 Apr 2020 19:04:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1588266293; bh=0fDAfdjWtXwDu+v6wdwaPU8DiaEi/9f+FV1wBeWE7uM=; h=Date:From:To:Subject:From; b=Wdfjk1V8JtT9e8h9wS6jRoiGV64IXk+pvbFSROA4j1RMP70gFaWUKvNvNuKJsCitR WrxWZUGIMYpuqB4gcncuH9LKB+nv9BVMV7gGGz+yF8PMIX8n81TkCSk9WinMltDk0d j9v19hld05oFLEzKd9pyCZh4v4ScAw1vNS4VIy9UY8xvO6tFFdBhXa99jg2TSyhahX wR2krVTdreTEXhI9fYqk4q/ZivnepC6YPJBtCLm7a9DqD/UieKEi0M4VIxOJjWl1NZ wprP9lIBGIUKnzQAytDUH1tKB0FweGU9lrjstzu81r8gdd3wUtgzf95acB1o0jo7S3 LAWM5iHsCZ+Og== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 49ChZY2PgYz6tmR for ; Thu, 30 Apr 2020 19:04:53 +0200 (CEST) Date: Thu, 30 Apr 2020 19:04:52 +0200 From: tuxic@posteo.de To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Trouble with backup harddisks Message-ID: <20200430170452.hsv6vcgzy43mluxq@solfire> Mail-Followup-To: gentoo-user@lists.gentoo.org References: <20200430093217.efprkpt4kbvir7nr@solfire> <5EAAA0AB.3050505@youngman.org.uk> <20200430103607.2xpawnms6wtqj7si@solfire> <5EAAC1E5.5060802@youngman.org.uk> <20200430131054.4qu3wlayohodrreu@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: <20200430131054.4qu3wlayohodrreu@nabokov.fritz.box> X-Archives-Salt: c7339bd7-a86c-4ef2-811e-a4b94ece9e45 X-Archives-Hash: 88213797efea2a48de469fe9c68d1e83 Hi Wolf thank you very much for your analysis ! :) On 04/30 03:10, Wynn Wolf Arbor wrote: > Hi, > > On 2020-04-30 13:17, Wols Lists wrote: > > All I can suggest is to check the kernel and see if it's an option that > > has been disabled (512-byte sectors, that is). > > As far as I know the kernel still uses 512 bytes internally [1], and I do > not recall having seen an option that enables or disables support for 512/4K > sectors. > > That said, the problem may well be stemming from a sector size discrepancy, > but as I understand it, it would have to do with how and when the partition > table was created. That is, like described in [2], some USB enclosures seem > to be a bit overzealous with obscure features, and might take eight disk > sectors and bundle them together into one 4K sector. > > If the disk was partitioned in the exact same enclosure, and is read from > the exact same enclosure right now, there shouldn't be any problems. Is this > the case, Meino? I have two external disks of that kind, same product, nearly the same contents, both have a "fixed case" (sorry...no native speaker...the case and the disk mechanics/electronics is "one thing"). > > Also, when did you last access the drives successfully, and with which > system? Three weeks ago...about...guessed...with my old system. Because these were backup disks I *NEVER* touch them with any partitioning tool whatsoever... It is complete unknown to me, what could have destroyed the partitioning... > On 2020-04-30 11:32, Meino wrote: > > Disk /dev/sdb: 931.49 GiB, 1000170586112 bytes, 1953458176 sectors > > Disk model: Elements 25A2 Units: sectors of 1 * 512 = 512 bytes > > Sector size (logical/physical): 512 bytes / 512 bytes > > I/O size (minimum/optimal): 512 bytes / 512 bytes > > > > Disklabel type: dos > > Disk identifier: 0x16f2a91f > > > > Device Boot Start End Sectors Size Id Type > > /dev/sdb1 1 1953458175 1953458175 931.5G ee GPT > > Interestingly, this reads *exactly* like the Protective MBR [3] that GPT > has. That is, the disklabel type is DOS whilst the partition ID is EE. > There's a single partition that spans the entire drive (and it's also > seemingly not aligned properly - usually you see Start at 2048). > As a comparison, here's the output from fdisk for the Protective MBR from > one of my GPT drives: > > > Disklabel type: dos > > Disk identifier: 0x00000000 > > > Device Boot Start End Sectors Size Id Type > > /dev/sdc1 1 4294967295 4294967295 2T ee GPT > > I'd assume that the missing disk identifier here is coming from different > tools writing the protective MBR differently. > > With that said, are you absolutely certain that you did not partition this > drive with GPT instead of MBR? YES! These drives were used as backup and as backup of the backup. I NEVER touched them with any partitioning tool after I had put a filesystem and data on it. > Did you do the partitioning in something like > fdisk (which asks you specifically what you want), or some other > application? Did you maybe format this drive on a Windows system? Windows? ....no thank you...all my windows here are transparent and open,.. ;) Joke aside.. No Windows (tm) here. The disks are used only with my Linux box using ext4 as filesystem. > > I'm not one to discount entirely strange things happening, but I have never > before seen a proper MBR laid out like a protective MBR. Indeed it would be > quite impossible to have systems access data through such a table, since the > partitions are hidden within that one huge contiguous block. > > Ordinarily I'd point to fdisk not reading the partition table properly, but > it seems that although your kernel has support for GPT, it doesn't seem to > see the partitions either (assuming a proper GPT exists at all). > Do you have some other GPT drives you can access successfully? With my new PC (my old MBR-based system was 12 years old and needed to be replaced. My kernel became "GPT aware onlu with my new PC. Everything before was based on MBR. My new PC can read GPT disks...my system is based on it. > > I'd say that this requires some more forensic work. Perhaps extracting the > first few megabytes of the disk and seeing whether there's a proper GPT or > not. This would of course require manual work. I copied the first 230GB of that disk to an empty partition of my new system and run "testdisk" on it....after the analysis it came back with "this partition cannot be recovered" but did not sau. whether the reason is a partition table, which is broken beyond repair, or simply due to the incomplete image file... > > A few more things to try: > > To see what the kernel uses for a particular disk, you can run the > following: cat /sys/block/sdb/queue/{physical,logical}_block_size host:/home/user>cat /sys/block/sdb/queue/physical_block_size 512 solfire:/home/user>cat /sys/block/sdb/queue/logical_block_size 512 host:/home/user> > fdisk takes a sector size with -b, --sector-size (should be non-destructive > as long as you don't write anything, but I am not sure). Also, fdisk has a > compatibility mode for dos with -c=dos. Might be worth a short. host:data/pool07>fdisk -c=dos testf.bin Welcome to fdisk (util-linux 2.35.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. GPT PMBR size mismatch (1953458175 != 455078119) will be corrected by write. DOS-compatible mode is deprecated. Command (m for help): p Disk testf.bin: 216.102 GiB, 232999997440 bytes, 455078120 sectors Geometry: 256 heads, 63 sectors/track, 28327 cylinders Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x16f2a91f Device Boot Start End Sectors Size Id Type testf.bin1 1 455078119 455078119 217G ee GPT Command (m for help): > fdisk should support GPT starting with util-linux 2.23, but you can also try > gptfdisk (it's in the tree). > > Hope this helps. > > [1] https://github.com/torvalds/linux/blob/master/include/linux/types.h#L120 > [2] https://superuser.com/questions/679725/how-to-correct-512-byte-sector-mbr-on-a-4096-byte-sector-disk/679800#679800 > [3] https://en.wikipedia.org/wiki/GUID_Partition_Table#PROTECTIVE-MBR > > -- > Wolf Thanks a lot Wolf!!! Cheers! Meino