Waarom is mijn flashdrive "alleen-lezen" geworden en (hoe) kan ik dat verhelpen?

Ik heb een gloednieuwe flashdrive (een week oud) die door Windows, Kubuntu en een bootable partitioner gemarkeerd is als alleen-lezen. Waarom is dit gebeurd? Is het te repareren? Zo ja, hoe kan ik dit oplossen?

Het probleem

Ten eerste, deze schijf is nieuw. Hij is zeker niet genoeg gebruikt om te overlijden aan normale slijtage, hoewel ik defecte onderdelen niet zou uitsluiten.

De schijf zelf is op een of andere manier vergrendeld in een alleen-lezen toestand. Schijfbeheer van Windows:

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

Diskpart:

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

Wat me echt in de war brengt zijn Current Read-only State : Yes en Read-only : No.

Geprobeerde oplossingen

Tot nu toe heb ik geprobeerd:

• Formatteren in Windows (in Schijfbeheer zijn de formatopties grijs als je er met de rechtermuisknop op klikt).

• DiskPart Clean (CLEAN - Clear the configuration information, or all information, off the disk.):

• Windows command line format

• Windows chkdsk: zie hieronder voor details

• Kubuntu fsck (via VirtualBox USB passthrough): zie hieronder voor details

• Acronis True Image om te formatteren, om te zetten naar GPT, om MBR te vernietigen en opnieuw op te bouwen, eigenlijk alles: mislukt (kon niet naar MBR schrijven)

Details (en een leuk verhaal)

Achtergrond

Dit was een gloednieuwe, generieke, 8GB flashdrive waarmee ik een multiboot flashdrive wilde maken. Hij kwam geformatteerd als FAT32, hoewel vreemd genoeg een beetje groter dan de meeste 8 GIGAbyte flash drives die ik ben tegengekomen. Ongeveer 127MB werd vermeld als “gebruikt” door Windows. Ik heb nooit ontdekt waarom. De uiteindelijk bruikbare ruimte was ongeveer wat ik normaal verwacht van een 8GB drive (ongeveer 7.4 GIBIbytes).

Ik had er een aantal Linux distro’s op gezet, samen met een kopie van Hiren’s. Ze zouden allemaal perfect opstarten. Ze waren erop gezet met YUMI .

Toen ik probeerde om de Knoppix DVD erop te zetten, voegde YUMI een vreemde video optie toe aan zijn bootcomman waardoor Knoppix opstartte met een zwart scherm op X. ttys 1 tot en met 6 werkten nog steeds als alleen tekst interfaces.

Een paar dagen later, nam ik de tijd om die vreemde video optie weg te halen, waardoor het opstart commando overeen kwam met degene die bij Knoppix geleverd wordt. Bij de poging om op te starten, rapporteerde Knoppix een vorm van LZMA corruptie.

Wat leidde tot het huidige probleem

Ik dacht dat de Knoppix bestanden misschien op de een of andere manier corrupt waren, dus probeerde ik het opnieuw te laden. De schijf was bijna vol (45MB vrij), dus verwijderde ik een generieke ISO die ook niet opstartte. Dat ging prima. Ik ging toen door YUMI om Knoppix te ‘de-installeren’, d.w.z. bestanden verwijderen en uit de menu’s verwijderen. De bestanden gingen eerst, daarna werden de menu’s met succes gewist. De vrije ruimte bleef echter steken op ongeveer 700MB, hetzelfde als het was voordat Knoppix verwijderd werd. In de oude Knoppix map was er een 0 byte bestand genaamd KNOPPIX dat niet verwijderd kon worden.

Ik probeerde de schijf opnieuw te plaatsen om dit bestand te verwijderen - zonder veilig te verwijderen, als dat een verschil maakte (hé, eerste keer voor alles). Het uitvoeren van de standaard Windows chkdsk scan zonder /r of /f rapporteerde gevonden fouten. Het uitvoeren met /r liet het gewoon vastlopen.

Ik besloot om fsck een kans te geven, dus ik laadde mijn Kubuntu VM en sloot de schijf aan met VirtualBox’s USB 2.0 passthrough. Ik umounted het (/dev/sda1) en liep een fsck. There are differences between boot sector and its backup. koos ik No action. Het vertelde me dat FATs verschillen en vroeg me om de eerste of tweede FAT te selecteren. Welke ik ook koos, ik kreeg een melding van Free cluster summary wrong. Als ik Correct koos, gaf het een lijst met onjuiste bestandsnamen. Om in ieder geval te proberen iets te repareren, startte ik het programma met de -p optie. Halverwege het repareren van de bestanden, bevroor de VM - ik beëindigde het proces ongeveer tien minuten later.

Oorzaak?

Mijn volgende poging was om YUMI te gebruiken, opnieuw, om de hele schijf te herbouwen. Ik gebruikte YUMI’s ingebouwde formatteringsoptie (naar FAT32) en installeerde een Kubuntu ISO (700MB). De formattering was succesvol, maar het uitpakken en kopiëren van Kubuntu (waar YUMI een 7zip binary voor gebruikt) bevroor op ongeveer 60%. Na ongeveer vijftien minuten wachten (langer dan de 3.5GB Knoppix ISO de vorige keer duurde), haalde ik de schijf eruit. De schijf was op dit punt al geformatteerd, SYSLINUX was al geïnstalleerd, het wachten was alleen nog op het uitpakken van een ISO en het aanpassen van de boot menu’s.

Toen ik hem er weer in stak, kwam hij er weer als normaal op - echter, iedere schrijfactie mislukte. Schijfbeheer meldde het als alleen-lezen. Bij het opnieuw aansluiten, kwam het als normaal, maar een schrijfoperatie veroorzaakte het om weer alleen-lezen te worden. Na een paar pogingen, begon hij als alleen-lezen te verschijnen bij het inbrengen.

Pogingen om

te herstellen Toen heb ik de bovenstaande pogingen ondernomen, om te proberen hem opnieuw te formatteren in geval van een foutief formaat. Het onvermogen om dit te doen, zelfs op een bootable disk, wees er echter op dat er iets ernstigers mis is. chkdsk meldt nu dat er niets mis is, en fsck meldt nog steeds MBR inconsistenties, maar kiest nu altijd automatisch de eerste FAT nadat hij me verteld heeft dat FAT’s verschillen. Het doet daarna nog steeds hetzelfde Free cluster summary wrong. Ik kan niet meer draaien met -p omdat het nu gemarkeerd is als alleen-lezen. Het is ook gelukt om de schijf van mijn VM op de een of andere manier corrupt maakte bij de eerste poging (ja, ik weet zeker dat ik sda koos, die gemapt is naar een 7.4GB schijf - ik heb het drievoudig gecontroleerd). Godzijdank voor snapshots?

• *

Ik heb bijna geen ideeën meer. Voor mijn onervaren geest lijkt het erop dat iets in de firmware van de schijf hem op een of andere manier “permanent” op alleen-lezen heeft gezet - is er een manier om dit te resetten? Ik geef er niet om dat de gegevens bewaard blijven, aangezien ik hem al twee keer opnieuw geformatteerd heb.

Ook fixes die me in Windows houden zijn beter; het vermindert de kans dat ik per ongeluk mijn harde schijf vernietig.

• *

Update 1:

Ik heb de schijf uit nieuwsgierigheid uit elkaar gehaald.

Zoals je kunt zien, zijn er geen duidelijke schrijfbeveiligingsschakelaars. Er zit een IC aan de andere kant, van het merk ALCOR, met het label AU6989HL, als dat iets uitmaakt. Als er geen manier blijkt te zijn om dit te verhelpen, zal ik waarschijnlijk de (vastgelijmde) kaart eruit halen en in een kaartlezer stoppen om te controleren of het de kaart of de controller is die overleden is.

• *

Update 2:

Ik heb de kaart eruit gehaald, Windows detecteert de drive nu als een kaartlezer. De contacten op de kaart lijken niet gebruikt te worden, en er zitten verschillende rijen gaatjes op de kaart zelf. Als je de kaart in de kaartlezer stopt, wordt er in totaal maar 30MB RAW gedetecteerd. Het is waarschijnlijk ofwel de originele drive die de kaart incorrect als defect rapporteert (alsof de schrijfbeveiliging van een echte SD-kaart is ingeschakeld) of een slecht contact ergens.

Als niets anders, ik heb een reserve 8GB Micro SD kaart nu … zodra ik erachter te komen hoe het te formatteren als 8GB. Wat niet mogelijk lijkt te zijn (Windows, Partedmagic, dd, DBAN… noppes, nog steeds 30MB). Ah wel.

• *

Update 3

Ik had nog een paar van deze. De tweede faalde ook (alleen lezen) vandaag. Van de resterende werden er twee gedetecteerd als lege kaartlezers/ongeformatteerde schijven, afhankelijk van het schudden (defect contact?). Eén werd gedetecteerd als 1/3 vol, en had een vreemde volumenaam.

H2testw resultaten (op de laatste volledig werkende die ik heb!):

Hoewel dit een beetje verontrustend is, hebben de drives blijkbaar echt een capaciteit van bijna 8 GB, zoals geverifieerd door een tool die vaak met succes wordt gebruikt om nep-flash drives op te sporen. Het gebruik van een Micro SD kaart in plaats van een gemarkeerde flash-geheugenmodule maakt het vrijwel onmogelijk om de drive te reflashen, omdat Alcor’s tools voor het flashen van drives het geheugenmodel als parameter verwachten. Ik denk dat ik de hele boel maar weggooi.