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 324A4138350 for ; Thu, 30 Apr 2020 13:11:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 89DCCE0946; Thu, 30 Apr 2020 13:11:03 +0000 (UTC) Received: from coleridge.oriole.systems (coleridge.oriole.systems [89.238.76.34]) (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 13AAEE093A for ; Thu, 30 Apr 2020 13:11:02 +0000 (UTC) Date: Thu, 30 Apr 2020 15:10:54 +0200 From: Wynn Wolf Arbor To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Trouble with backup harddisks Message-ID: <20200430131054.4qu3wlayohodrreu@nabokov.fritz.box> Mail-Followup-To: Wynn Wolf Arbor , gentoo-user@lists.gentoo.org References: <20200430093217.efprkpt4kbvir7nr@solfire> <5EAAA0AB.3050505@youngman.org.uk> <20200430103607.2xpawnms6wtqj7si@solfire> <5EAAC1E5.5060802@youngman.org.uk> 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=utf-8; format=flowed Content-Disposition: inline In-Reply-To: <5EAAC1E5.5060802@youngman.org.uk> X-Archives-Salt: dac929d9-bd33-4f17-89c5-4fa762d024fc X-Archives-Hash: 7f3ecae5a15e5110feb7cc0a19c1312b 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? Also, when did you last access the drives successfully, and with which system? 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? 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? 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? 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. 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 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. 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