P
PeFri
Neues Mitglied
- 17
@frank_m
Ja, das wäre nun geklärt. Vielen Dank!
Meine Mißverständnis war, ich hatte angenommen, deine Linux-Methode könnte jegliche von Software verursachte 'Sperre' der Karte beseitigen, und dass mir u.U. nur noch ein geeigneter low-level Linuxbefehl für das Setzen der notwendigen Schreibberechtigung für dd und fdisk fehlte.
Wenn es ihn gibt, dann fehlt er mir immer noch!
Meine kaputte 32GB Sandisk Class 10 UHS1 Karte verhält sich zwar wie physikalisch kaputt: dd und fdisk gelingt es nicht sie zu beschreiben. Aber ist sie wirklich physikalisch kaputt? Oder doch nur 'scheintot'? D.h. physikalisch in Ordnung aber elektronisch schreib-'gesperrt'? Eine Art irrtümlich vom Tab verursachte 'DRM-artige'-Sperre der ganzen Karte?
Es geht mir dabei nicht nur um diese eine Karte sondern darum, ob es eine Methode gibt, die vom Tab verursachten Probleme zu beheben oder zumindest diesen Problemen vorzubeugen. Sonst bleibt für das Tab7.7 nur ropbin's Rat "don't buy sandisk UHS1 product (for Tab7.7)"!
Bevor ich weiter teste und weitere SDXC-Karten aufs Spiel setze, könnten mir noch einige spezielle fdisk Tipps helfen. In meiner GoPro Hero2 habe ich eine SanDisK 32GB Class 10 UHS1. Die könnte ich als nächste dem Tab7.7 Problem opfern. Sie wurde von der Hero2 formatiert und hat folgende Eigenschaften:
Wie ist das mit den Angaben in der zweiten Listen-Zeile (Köpfe, usw.)?
Insbesondere, wie ist das mit den Köpfen? Diese 32GB-Karte hat 28, die andere (kaputte) 32 GB-Karte hatte 64 Köpfe? Von den 64 GB-Karten hatte die neue, noch unbenutzte 255 (255 Köpfe, 63 Sektoren/Spur, 7764 Zylinder) bzw. die ältere, im S2 gut funktionierende 256 Köpfe (256 Köpfe, 63 Sektoren/Spur, 7734 Zylinder)! Wer legt das fest? Wieviele Köpfe haben deine funktionierende 64 GB Karten? Könntest du bitte von diesen auch so eine Liste wie ich sie beigelegt habe, beilegen? Hast du die Köpfe (Heads) und die anderen Parameter im fdisk eingestellt oder genommen, wie es war?
Die gleiche Frage für das DOS Kompatibilitätsflag. Sollte das DOS Kompatibilitätsflag gesetzt sein oder nicht? Bei der GoPro Hero2 Karte war es nicht gesetzt. (Das sieht man nicht in der p-Liste, sondern durch 'Togglen' mit dem fdisk c-Kommando:
(Der zweite Befehl schaltet auf den ursprünglichen Ausgangszustand zurück)
Laut Google Translation bedeutet 'DEPRECATED' veraltet. Dann wohl besser nicht gesetzt?
Die Filesystem Id steht auf 'b', bei Auslieferung auf 'c'. Was benötigt das Tab7.7 'b' oder 'c', oder spielt es keine Rolle?
Wenn ich da klarer sehe, werde ich noch die kleine 32GB SD-Karte aus dem GoPro Hero2 riskieren um herauszufinden, ob die Vorbeugung durch Anwendung deiner Methode (oder der Variante von bex0rs) _vor_ dem ersten Einlegen in das Tab was nützt und die Karte vor dem 'kaputt' werden schützen kann. Dazu würde ich als Soll-Vorgabe eine Auflistung des Partition-Kennsatzes _nach_ Anwendung deiner Methode benötigen.
Ja, das wäre nun geklärt. Vielen Dank!
Meine Mißverständnis war, ich hatte angenommen, deine Linux-Methode könnte jegliche von Software verursachte 'Sperre' der Karte beseitigen, und dass mir u.U. nur noch ein geeigneter low-level Linuxbefehl für das Setzen der notwendigen Schreibberechtigung für dd und fdisk fehlte.
Wenn es ihn gibt, dann fehlt er mir immer noch!
Meine kaputte 32GB Sandisk Class 10 UHS1 Karte verhält sich zwar wie physikalisch kaputt: dd und fdisk gelingt es nicht sie zu beschreiben. Aber ist sie wirklich physikalisch kaputt? Oder doch nur 'scheintot'? D.h. physikalisch in Ordnung aber elektronisch schreib-'gesperrt'? Eine Art irrtümlich vom Tab verursachte 'DRM-artige'-Sperre der ganzen Karte?
Es geht mir dabei nicht nur um diese eine Karte sondern darum, ob es eine Methode gibt, die vom Tab verursachten Probleme zu beheben oder zumindest diesen Problemen vorzubeugen. Sonst bleibt für das Tab7.7 nur ropbin's Rat "don't buy sandisk UHS1 product (for Tab7.7)"!
Bevor ich weiter teste und weitere SDXC-Karten aufs Spiel setze, könnten mir noch einige spezielle fdisk Tipps helfen. In meiner GoPro Hero2 habe ich eine SanDisK 32GB Class 10 UHS1. Die könnte ich als nächste dem Tab7.7 Problem opfern. Sie wurde von der Hero2 formatiert und hat folgende Eigenschaften:
Code:
Disk /dev/sdb: 31.9 GB, 31914983424 bytes
28 Köpfe, 51 Sektoren/Spur, 43651 Zylinder, zusammen 62333952 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Gerät boot. Anfang Ende Blöcke Id System
/dev/sdb1 * 8192 62333951 31162880 b W95 FAT32Insbesondere, wie ist das mit den Köpfen? Diese 32GB-Karte hat 28, die andere (kaputte) 32 GB-Karte hatte 64 Köpfe? Von den 64 GB-Karten hatte die neue, noch unbenutzte 255 (255 Köpfe, 63 Sektoren/Spur, 7764 Zylinder) bzw. die ältere, im S2 gut funktionierende 256 Köpfe (256 Köpfe, 63 Sektoren/Spur, 7734 Zylinder)! Wer legt das fest? Wieviele Köpfe haben deine funktionierende 64 GB Karten? Könntest du bitte von diesen auch so eine Liste wie ich sie beigelegt habe, beilegen? Hast du die Köpfe (Heads) und die anderen Parameter im fdisk eingestellt oder genommen, wie es war?
Die gleiche Frage für das DOS Kompatibilitätsflag. Sollte das DOS Kompatibilitätsflag gesetzt sein oder nicht? Bei der GoPro Hero2 Karte war es nicht gesetzt. (Das sieht man nicht in der p-Liste, sondern durch 'Togglen' mit dem fdisk c-Kommando:
Code:
Befehl (m für Hilfe): c
DOS Compatibility flag is set (DEPRECATED!)
Befehl (m für Hilfe): c
DOS-Kompatibilitätsflag ist nicht gesetztLaut Google Translation bedeutet 'DEPRECATED' veraltet. Dann wohl besser nicht gesetzt?
Die Filesystem Id steht auf 'b', bei Auslieferung auf 'c'. Was benötigt das Tab7.7 'b' oder 'c', oder spielt es keine Rolle?
Wenn ich da klarer sehe, werde ich noch die kleine 32GB SD-Karte aus dem GoPro Hero2 riskieren um herauszufinden, ob die Vorbeugung durch Anwendung deiner Methode (oder der Variante von bex0rs) _vor_ dem ersten Einlegen in das Tab was nützt und die Karte vor dem 'kaputt' werden schützen kann. Dazu würde ich als Soll-Vorgabe eine Auflistung des Partition-Kennsatzes _nach_ Anwendung deiner Methode benötigen.
Zuletzt bearbeitet:
(weil die Händler bei denen man so um 40€ Freihaus die Karte bekommen kann gibt es noch nicht viele).
)
. Hört sich nach einem schlechtem Witz an. Die Karte hat zuverlässig die Stressteste an einem Laptop bestanden. Auch der Kopiervorgang im Tab war auf FAT32 Partition erfolgreich - die Dateien ließen sich danach aber nicht lesen, die Karte ging aber immer noch am Laptop. Auf NTFS umformatiert, mit Paragon NTFS gemountet, Kopiervorgang und voilà - die Karte war tot, ließ sich am Laptop nicht mal erkennen bzw. formatieren. Also irgendwas macht der Tabby schon falsch.