Re: [gentoo-user] Trouble with backup harddisks

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