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
