Diese Frage hat hier bereits eine Antwort:
Ich habe ein brandneues Flash-Laufwerk (eine Woche alt), das von Windows, Kubuntu und einem bootfähigen Partitionierer als schreibgeschützt markiert wurde. Warum ist das passiert? Ist es reparabel? Wenn ja, wie kann ich das beheben?
Das Problem
Erstens ist dieses Laufwerk neu. Es ist sicherlich nicht genug verwendet worden, um an normalem Verschleiß zu sterben, obwohl ich defekte Komponenten nicht rabattieren würde.
Das Laufwerk selbst ist irgendwie schreibgeschützt. Windows-Datenträgerverwaltung:
Diskpart:
Generic Flash Disk USB Device
Disk ID: 33FA33FA
Type : USB
Status : Online
Path : 0
Target : 0
LUN ID : 0
Location Path : UNAVAILABLE
Current Read-only State : Yes
Read-only : No
Boot Disk : No
Pagefile Disk : No
Hibernation File Disk : No
Crashdump Disk : No
Clustered Disk : No
Was mich wirklich verwirrt ist Current Read-only State : Yes
und Read-only : No
.
Versuchte Lösungen
Bisher habe ich versucht:
Formatieren in Windows (in der Datenträgerverwaltung sind die Formatoptionen beim Klicken mit der rechten Maustaste ausgegraut).
DiskPart Clean (
CLEAN - Clear the configuration information, or all information, off the disk.
):DISKPART> clean DiskPart has encountered an error: The media is write protected. See the System Event Log for more information.
Das Ereignisprotokoll enthielt nichts.
Windows-Befehlszeilenformat
>format G: Insert new disk for drive G: and press ENTER when ready... The type of the file system is FAT32. Verifying 7740M Cannot format. This volume is write protected.
Windows chkdsk: Einzelheiten finden Sie weiter unten
Kubuntu fsck (über VirtualBox USB Passthrough): Einzelheiten siehe unten
Acronis True Image zu formatieren, zu GPT zu konvertieren, MBR zu zerstören und neu zu erstellen, im Grunde genommen alles: fehlgeschlagen (konnte nicht in MBR schreiben)
Details (und eine schöne Geschichte)
Hintergrund
Dies war ein brandneues, generisches 8-GB-Flash-Laufwerk, mit dem ich ein Multiboot-Flash-Laufwerk erstellen wollte. Es wurde als FAT32 formatiert, obwohl es merkwürdigerweise etwas größer war als die meisten 8 GIGAbyte-Flash-Laufwerke, auf die ich gestoßen bin. Ungefähr 127 MB wurden von Windows als "verwendet" eingestuft. Ich habe nie herausgefunden warum. Der nutzbare Speicherplatz entsprach ungefähr dem, was ich normalerweise von einem 8-GB-Laufwerk erwarte (ca. 7,4 GIBI-Byte).
Ich hatte einige Linux-Distributionen zusammen mit einer Kopie von Hirens aufgelegt. Sie würden alle perfekt booten. Sie wurden mit YUMI angelegt .
Als ich versuchte, die Knoppix-DVD einzulegen, fügte YUMI seinem Boot-Kommando eine ungerade Video-Option hinzu, die dazu führte, dass Knoppix mit einem schwarzen Bildschirm auf X bootete tty
.
Ein paar Tage später nahm ich mir etwas Zeit, um diese seltsame Videooption zu deaktivieren, sodass der Startbefehl mit dem übereinstimmt, der mit Knoppix geliefert wird. Bei dem Versuch zu booten, meldete Knoppix irgendeine Form von LZMA-Beschädigung.
Vorwort zur aktuellen Ausgabe
Ich dachte, die Knoppix-Dateien könnten irgendwie beschädigt sein, also habe ich versucht, sie neu zu laden. Das Laufwerk war fast voll (45 MB frei), daher habe ich ein generisches ISO gelöscht, das auch nicht bootete. Das ging gut. Ich ging dann durch YUMI, um Knoppix 'zu deinstallieren', dh Dateien zu löschen und aus den Menüs zu entfernen. Die Dateien gingen zuerst, dann wurden die Menüs erfolgreich gelöscht. Der freie Speicherplatz war jedoch auf etwa 700 MB beschränkt, genau wie vor dem Entfernen von Knoppix. Im alten Knoppix-Ordner gab es eine 0-Byte-Datei mit dem Namen KNOPPIX
, die nicht gelöscht werden konnte.
Ich habe versucht, das Laufwerk erneut einzulegen, um diese Datei zu löschen - ohne sie sicher zu entfernen, falls dies einen Unterschied machte (hey, erstmal für alles). Ausführen des Standard-Windows- chkdsk
Scans ohne /r
oder /f
gemeldete Fehler gefunden. Laufen mit /r
habe es gerade stecken.
Ich habe beschlossen, fsck
einen Versuch zu starten, also habe ich meine Kubuntu-VM geladen und das Laufwerk mit dem USB 2.0-Passthrough von VirtualBox daran angeschlossen. Ich habe umount
es /dev/sda1
editiert ( ) und ein fsck ausgeführt. There are differences between boot sector and its backup.
Ich habe gewählt No action
. Es wurde mir mitgeteilt, dass die FATs unterschiedlich sind, und ich wurde gebeten, entweder die erste oder die zweite FAT auszuwählen. Was auch immer ich ausgewählt habe, ich habe eine Nachricht bekommen Free cluster summary wrong
. Wenn ich wählte Correct
, gab es eine Liste der falschen Dateinamen. Um zumindest etwas zu reparieren , habe ich es mit der -p
Option ausgeführt. Auf halbem Weg nach dem Reparieren der Dateien fror die VM ein - ich beendete den Vorgang ungefähr zehn Minuten später.
Ursache?
Mein nächster Versuch war, YUMI erneut zu verwenden, um das gesamte Laufwerk neu zu erstellen. Ich habe die in YUMI eingebaute Option zur Neuformatierung (auf FAT32) verwendet und eine Kubuntu-ISO (700 MB) installiert. Das Format war jedoch erfolgreich, das Extrahieren und Kopieren von Kubuntu (für das YUMI eine 7zip-Binärdatei verwendet) erstarrte bei etwa 60%. Nachdem ich ungefähr fünfzehn Minuten gewartet hatte (länger als das letzte Mal bei Knoppix ISO mit 3,5 GB), zog ich das Laufwerk heraus. Das Laufwerk war zu diesem Zeitpunkt bereits formatiert, SYSLINUX bereits installiert und wartete nur auf das Entpacken einer ISO und das Ändern der Startmenüs.
Wenn Sie es wieder einstecken, wird es wie gewohnt angezeigt. Schreibvorgänge schlagen jedoch fehl. Die Datenträgerverwaltung hat dies als schreibgeschützt gemeldet. Beim erneuten Verbinden würde es wie gewohnt angezeigt, aber bei einem Schreibvorgang wird es nur noch einmal gelesen. Nach einigen Versuchen wurde es beim Einfügen als schreibgeschützt angezeigt.
Versuche zu beheben
In diesem Fall habe ich die oben aufgeführten Versuche durchlaufen, um zu versuchen, es im Falle eines fehlerhaften Formats neu zu formatieren. Die Unfähigkeit, dies auch auf einer bootfähigen Festplatte zu tun, deutet jedoch darauf hin, dass etwas Schwerwiegenderes nicht stimmt. chkdsk
Jetzt wird gemeldet, dass nichts falsch ist, und es werden fsck
weiterhin MBR-Inkonsistenzen gemeldet. Jetzt wird immer automatisch die erste FAT ausgewählt, nachdem mir mitgeteilt wurde, dass die FATs unterschiedlich sind. Free cluster summary wrong
Danach geht es immer noch genauso . Ich kann nicht mehr mit ausführen, -p
da es jetzt als schreibgeschützt markiert ist. Es gelang mir auch, die Festplatte meiner VM beim ersten Versuch irgendwie zu beschädigen (ja, ich bin sicher, ich habe sda gewählt, das einem 7,4-GB-Laufwerk zugeordnet ist - ich habe es dreifach überprüft). Gott sei Dank für Schnappschüsse?
Ich habe einfach keine Ideen mehr. Meiner Meinung nach scheint die Firmware des Laufwerks so eingestellt zu sein, dass sie nur "permanent" lautet. Gibt es eine Möglichkeit, dies zurückzusetzen? Die Aufbewahrung von Daten ist mir nicht besonders wichtig, da ich sie zweimal neu formatiert habe.
Außerdem sind Korrekturen, die mich in Windows halten, besser. Dies verringert das Risiko, dass ich versehentlich meine Hauptfestplatte beschädige.
Update 1:
Aus Neugier zog ich die Einfahrt auseinander.
Wie Sie sehen, gibt es keine offensichtlichen Schreibschutzschalter. Auf der anderen Seite befindet sich ein IC mit der Bezeichnung AU6989HL von ALCOR, falls dies von Bedeutung ist. Wenn es keine Möglichkeit gibt, dies zu beheben, ziehe ich wahrscheinlich die (verklebte) Karte heraus und stecke sie in einen Kartenleser, um zu überprüfen, ob es die Karte oder der Controller ist, der gestorben ist.
Update 2:
Ich habe die Karte herausgezogen, Windows erkennt das Laufwerk jetzt als Kartenleser. Die Kontakte auf der Karte scheinen nicht verwendet zu werden, und auf der Karte selbst befinden sich mehrere Lochreihen. Wenn Sie es in den Kartenleser stecken, werden insgesamt nur 30 MB RAW erkannt. Es ist wahrscheinlich entweder das Originallaufwerk, das die Karte fälschlicherweise als fehlerhaft meldet (als wäre der Schreibschutz einer echten SD-Karte aktiviert), oder irgendwo ein schlechter Kontakt.
Wenn nichts anderes, habe ich jetzt eine 8 GB Micro SD-Ersatzkarte ... sobald ich herausgefunden habe, wie ich sie als 8 GB formatieren kann. Was anscheinend nicht möglich ist (Windows, Partedmagic dd
, DBAN ... nein, immer noch 30MB). Ah, gut.
Update 3
Ich hatte noch ein paar davon. Das zweite ist heute ähnlich (schreibgeschützt) gescheitert. Von den verbleibenden wurden zwei als leere Kartenleser / unformatierte Laufwerke je nach Erschütterung (fehlerhafter Kontakt?) Erkannt. Einer wurde als 1/3 voll erkannt und hatte einen ungeraden Datenträgernamen.
H2testw Ergebnisse (auf dem letzten voll funktionsfähigen, den ich habe!):
Warning: Only 7762 of 7812 MByte tested.
The media is likely to be defective.
7.5 GByte OK (15896472 sectors)
52 KByte DATA LOST (104 sectors)
Details:0 KByte overwritten (0 sectors)
0 KByte slightly changed (< 8 bit/sector, 0 sectors)
52 KByte corrupted (104 sectors)
0 KByte aliased memory (0 sectors)
First error at offset: 0x0000000186003000
Expected: 0x0000000186003000
Found: 0x00200800c40c3061
H2testw version 1.3
Writing speed: 3.95 MByte/s
Reading speed: 14.0 MByte/s
H2testw v1.4
Dies ist zwar ein wenig besorgniserregend, aber offenbar haben die Laufwerke tatsächlich eine Kapazität von fast 8 GB, was durch ein Tool überprüft wird, das häufig erfolgreich zum Erkennen von gefälschten Flash-Laufwerken verwendet wird. Die Verwendung einer Micro-SD-Karte anstelle eines gekennzeichneten Flash-Speichermoduls macht ein erneutes Speichern des Laufwerks nahezu unmöglich, da die Flash-Tools von Alcor das Speichermodell als Parameter erwarten. Ich denke, ich werfe einfach die ganze Menge raus.
Windows Logs
und Applications and Services Logs
. Da passiert nichts. Ja, ich habe refresh ( F5
) kontinuierlich ausgeführt.