Linux (exfat-fuse) kann nicht von einer externen GPT-4-TB-exFAT-Festplatte lesen

1045
Afforess

Ich habe ein 4Tb externes WD RED. Es wurde als exFAT-Diskette auf einem Windows 10-Computer formatiert. Ich habe kein Problem damit, die Dateien sowohl vom ursprünglichen Windows 10-Computer als auch von einem 2017 Macbook Pro (High Sierra) zu lesen.

Auf beiden Linux-Computern (Ubuntu 16.10 x64 + Slackware 14.2) erkennt das System den Datenträger niemals als lesbar oder als montierbar. Wenn ich die Diskette auf meinem Linux-Rechner als exFAT lösche und formatiere, kann weder der Windows-10-Computer noch das Macbook sie lesen, obwohl beide Linux-Geräte dies können. Das lässt vermuten, dass die Implementierung von Exfat-Fuse unvollständig ist ... obwohl ich zugegebenermaßen nicht genug weiß, um sicher zu sein.

[Als Randbemerkung löschte ich auch das als exFAT formatierte Format aus dem Macbook Pro und der Windows 10-Computer konnte immer noch lesen / schreiben. Keine Linux-Maschine könnte das.]

Folgendes habe ich bisher untersucht:

sudo lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT ... sdj 8:144 0 3.7T 0 disk  ├─sdj1 8:145 0 6.4G 0 part  └─sdj2 8:146 0 7.3G 0 part

Beachten Sie die Speichergrößen der Dateisysteme, die von lsblk erkannt werden. Das Volume ist mit nur einer exFAT-Partition formatiert, die alle 4 TB umfasst.

parted -l /dev/sdj

Error: /dev/sdj: unrecognised disk label Model: WDC WD40 EZRZ-00GXCB0 (scsi)  Disk /dev/sdj: 4001GB Sector size (logical/physical): 512B/4096B Partition Table: unknown Disk Flags:

parted ist zumindest ehrlich genug zu sagen, dass es keine Ahnung hat, womit wir uns befassen. Es hat das Modell richtig erkannt, es ist ein WD Rot 4 TB.

fdisk -l /dev/sdj

Disk /dev/sdj: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0x3258a7ab  Device Boot Start End Sectors Size Id Type /dev/sdj1 1 76805 76805 37.5M ee GPT /dev/sdj2 77056 976754431 976677376 465.7G 7 HPFS/NTFS/exFAT

Die Ausgabe von fdisk ist interessant, weil sie fast richtig ist. Es bildet eine Partition als GPT-Metadaten ab. Der andere findet die ID (0x07 == Microsoft Data ) korrekt, aber die Größe stimmt nicht. Die Partition ist 4 TB, nicht 465,7 GB.

Ich überprüfte, dass die Partition wirklich 4 TB umfasst, indem ich 4 TB Testinhalt aus Windows schreibe und den gesamten Inhalt erfolgreich wieder vom Macbook Pro abliest.

Der Versuch, eines der erkannten Geräte bereitzustellen, funktioniert nicht:

sudo mount.exfat-fuse -d /dev/sdj1 /mnt/foobar

FUSE exfat 1.2.4 ERROR: exFAT file system is not found.

sudo mount.exfat-fuse -d /dev/sdj2 /mnt/foobar

FUSE exfat 1.2.4 ERROR: exFAT file system is not found.

Exfat-Fuse druckt auch im Debug-Modus keine nützliche Ausgabe. Wenn man sich die Quelle ansieht, scheitert es sehr früh, gleich nachdem man den Superblock gelesen hat.

Ich habe einen Blick auf die ersten 1 MB Daten auf dem Gerät mit einem Hexdump geworfen, und es sieht gesund aus, ohne offensichtlichen Müll. (Pastebin: https://pastebin.com/BVLWW3kf )

Irgendwelche weiteren Debugging-Schritte, die ich versuchen sollte? Irgendwelche Ideen, was hier los ist?

Bearbeiten:

Mit gdiskscheint es, das Laufwerk einen Hybrid - MBR + GPT hat. Gdisk erkennt jedoch die GPT als ungültig:

sudo gdisk /dev/sdj GPT fdisk (gdisk) version 1.0.1  Partition table scan: MBR: hybrid BSD: not present APM: not present GPT: not present  *************************************************************** Found invalid GPT and valid MBR; converting MBR to GPT format in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by typing 'q' if you don't want to convert your MBR partitions to GPT format! ***************************************************************
1
Ich vermute, die Platte enthält eine GPT-Partitionstabelle UND eine MBR-Partitionstabelle (nicht die absurden Größen von sdj1 und sdj2). Unter Windows und Mac wird der GPT unter Linux MBR verwendet. Haben Sie "gptsync" oder Freunde versucht, um dies auszuschließen? Eugen Rieck vor 6 Jahren 2
"gptsync" liest die GPT-Tabelle nicht: https://pastebin.com/r2GswgBL Sie haben jedoch Recht, sie haben eine MBR-Tabelle erkannt. Afforess vor 6 Jahren 0
Das könnte es erklären! Windows und Mac verwenden eine GPT-Partitionstabelle, bei der nur die sekundäre (Backup-) Version ohne Beanstandung vorhanden ist, Linux jedoch nicht. Sie könnten versuchen, Anfang und Ende zu löschen (Partitionstabellen MBR, GPT-Primär, GPT-Sicherung) und dann die Partitionierung unter Linux mit gdisk durchführen. Dies sollte funktionieren. Eugen Rieck vor 6 Jahren 0
Ich versuche das - aber ich bin neugierig, warum Linux der Meinung ist, dass die GPT ungültig ist. Es ist eindeutig genug, dass Windows und MacOS es lesen können. Afforess vor 6 Jahren 0
Eine GPT-Partitionstabelle ist zweimal vorhanden. Windows und MacOS verwenden sie, wenn eine Kopie in Ordnung ist. Linux ist vorsichtiger Eugen Rieck vor 6 Jahren 0
Ich bin mir ziemlich sicher, dass der Linux-Kernel das Backup-GPT gut verwenden wird. parted und gdisk werden Sie sicherlich wissen lassen, dass das Primärsystem beschädigt ist, und bieten an, es mithilfe der Sicherung zu reparieren. psusi vor 6 Jahren 0
Die Tools werden es tun - aber der Kernel erkennt die Partitionen nicht automatisch Eugen Rieck vor 6 Jahren 0
Ich bin mir nicht sicher, ob irgendetwas mit dem GPT nicht stimmt. Es scheint, dass das Kernproblem die 512e vs 4k ist und dass Linux denkt, dass das Laufwerk 512e ist. Afforess vor 6 Jahren 0

1 Antwort auf die Frage

3
psusi

Das Problem scheint zu sein, dass der Datenträger so partitioniert wurde, als wäre er ein Datenträger mit einer Größe von 4 KB. Die GPT beginnt bei 4096 Bytes. Da es sich um ein 512e-Laufwerk handelt, sollte es mit 512 Byte in den Datenträger starten. Ich würde vermuten, dass Windows aus irgendeinem Grund das Laufwerk falsch als 4kn erkennt.

Es ist eine Festplatte mit 4k nativer Sektorgröße. WD übernahm zuerst die 4ke-Spezifikation (und das Laufwerk ist brandneu). Es ist Linux, das es nicht richtig erkennt. Afforess vor 6 Jahren 0
Eigentlich frage ich mich, ob das USB-Gehäuse daran schuld ist. Die Ausgabe von "gdisk" ist sinnvoll, wenn Sie sie mit 8 multiplizieren (4096/512 -> 8). Dies legt nahe, dass die Linux-Tools es als 512e lesen, wenn es 4k ist. Afforess vor 6 Jahren 0
(Ich habe diese Antwort angehört, aber ich stelle es nicht richtig dar, weil es streng genommen nicht der Fall ist. Es ist jedoch in der Nähe.) Afforess vor 6 Jahren 0
@Aforforess, wenn Sie über Windows darauf zugreifen, verwenden Sie dasselbe Gehäuse? Wenn nicht, würde dies erklären, woher der 512e kommt: Es ist das Gehäuse. psusi vor 6 Jahren 0
Ich habe dasselbe Gehäuse benutzt. Afforess vor 6 Jahren 0
@Aforforess, ich frage mich, ob Windows es als 4k oder 512 erkennt. Ich frage mich, ob es eine Problemumgehung gibt, bei der ein GPT angezeigt wird, das behauptet, es sei 4k, dann geht es mit dem, was das Laufwerk sagt. psusi vor 6 Jahren 0
Gibt es eine einfache Möglichkeit, herauszufinden, auf welche Weise Windows die Festplatte sieht? Afforess vor 6 Jahren 0

Verwandte Probleme