2

I have just opened an external USB 3.0 hard disk enclosure and mounted the disk instead internally in a PC via SATA. Now, the Linux system stops finding the GPT which was certainly there. Since there are already 2 TB of data on the disk it would be nice to find the partition table which is already there.

Can the location of the GPT change when using a different interface (USB, SATA)? How can it be fixed?

Here is the gdisk output mounted in the PC (SATA):

# gdisk /dev/disk/by-id/ata-TOSHIBA_DT01ABA300_123456890
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries.

Command (? for help): q

The disk is a TOSHIBA DT01ABA300 (as you can see above) and was in a Toshiba Canvio USB3 enclosure.

Here is the relevant portion of dmesg:

[    1.618441] scsi host9: ahci
[    1.618485] ata9: SATA max UDMA/133 abar m512@0xfd1ff000 port 0xfd1ff100 irq 42
[    2.106001] ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    2.107329] ata9.00: ATA-8: TOSHIBA DT01ACA300, MX6OABB0, max UDMA/133
[    2.107332] ata9.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
[    2.108712] ata9.00: configured for UDMA/133
[    2.609553] scsi 9:0:0:0: Direct-Access     ATA      TOSHIBA DT01ABA3 ABB0 PQ: 0 ANSI: 5
[    2.609699] sd 9:0:0:0: [sdg] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[    2.609703] sd 9:0:0:0: [sdg] 4096-byte physical blocks
[    2.609785] sd 9:0:0:0: [sdg] Write Protect is off
[    2.609788] sd 9:0:0:0: [sdg] Mode Sense: 00 3a 00 00
[    2.609825] sd 9:0:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.637653] sd 9:0:0:0: [sdg] Attached SCSI disk

Here is where I found the EFI (GPT?!) signature on the raw disk:

dd if=/dev/sdg bs=2M count=32 | hexdump -C | grep -w EFI
32+0 records in
32+0 records out
67108864 bytes (67 MB) copied, 0.447864 s, 150 MB/s
00001000  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|

I did not find a gdisk parameter to read the GPT from a particular offset. How can I read it?

# parted /dev/sdg
GNU Parted 3.2
Using /dev/sdg
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit b                                                           
(parted) print                                                            
Error: /dev/sdg: unrecognised disk label
Model: ATA TOSHIBA DT01ABA3 (scsi)                                        
Disk /dev/sdg: 3000592982016B
Sector size (logical/physical): 512B/4096B
Partition Table: unknown
Disk Flags: 
(parted) q

And:

# losetup --find --show /dev/sdg
/dev/loop0
# parted /dev/loop0
GNU Parted 3.2
Using /dev/loop0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit b                                                           
(parted) print                                                            
Error: /dev/loop0: unrecognised disk label
Model: Loopback device (loopback)                                         
Disk /dev/loop0: 3000592982016B
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags: 
(parted)
  • It definitely shouldn't, assuming of course that the enclosure is well-behaved... – a CVn Oct 29 '15 at 13:54
  • That's what I hoped, but where has the partition gone? – Ned64 Oct 29 '15 at 13:57
  • Let's see the relevant portion of the partition scan output from the kernel initialization (use dmesg | less) – a CVn Oct 29 '15 at 14:03
  • @MichaelKjörling Done. Hope nothing is missing. No partition output for this disk in dmesg. – Ned64 Oct 29 '15 at 14:32
  • Output of parted /dev/disk unit b print and parted $(losetup --find --show /dev/disk) unit b print? – frostschutz Oct 29 '15 at 14:46
2

Can the location of the GPT change when using a different interface (USB, SATA)?

Yes, because GPT is stupid and depends on sector size, and some USB enclosures claim 512b sectors when it's really 4096b sectors or vice versa.

Yes, because Linux is stupid and does not support GPT for differing block sizes even though it should be possible to detect this automatically.

You might have to re-create the partition table to convert from GPT-512 to GPT-4096 and hope the partitions were MiB-aligned to allow such conversions in the first place.

  • Thanks. Can I find and read the relevant sector (with the GPT) on the disk and open gdisk with the correct offset? (Partitions were MB-aligned, that will be no problem.) – Ned64 Oct 29 '15 at 14:36
  • Added location of GPT above, can I read it somehow (and write it to the correct location / re-create)? – Ned64 Oct 29 '15 at 14:52
  • Your GPT is using 4K sectors so if that does not work and no partitioning software is smart enough to understand it either, you somehow have to emulate a device with 4K sectors. If the enclosure is still available, easiest solution might be to just read the partition table from there. – frostschutz Oct 29 '15 at 14:54
  • I have three SATA controllers in my PC. Could it be a different one will suppport the 4K feature of the disk? (I would just try but rebooting takes ages...) – Ned64 Oct 29 '15 at 15:00
  • 2
    Done it! First copied the old GPT (with 4k units) to the correct location, like so: dd if=/dev/sdg bs=2M count=32 > sdg then dd if=sdg bs=256 skip=16 count=1 of=/dev/sdg seek=2 and dd if=sdg bs=256 skip=32 count=1 of=/dev/sdg seek=4. Read contents of old GPT with gdisk /dev/sdg, wrote down all details (start/end/type of partitions), multiplied those 4k-addresses by 8 to get 512b-sectors, then zapped GPT by dd if=/dev/zero bs=4k count=3 of=/dev/sdg, then re-created new GPT with gdisk /dev/sdg and new addresses. All data is still there :-) – Ned64 Oct 29 '15 at 18:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.