Re: [gentoo-user] Trouble with backup harddisks

[Wynn Wolf Arbor]

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