Pourquoi ma clé USB est-elle devenue "lecture seule" et comment puis-je la réparer ?

J'ai une clé USB toute neuve (une semaine) qui a été marquée comme étant en lecture seule par Windows, Kubuntu et un partitionneur amorçable. Pourquoi cela s'est-il produit ? Est-il possible de le réparer ? Si c'est le cas, comment puis-je résoudre ce problème ?

Le problème

Tout d'abord, ce disque est neuf. Il n'a certainement pas été assez utilisé pour mourir d'une usure normale, bien que je n'écarte pas la possibilité de composants défectueux.

Le disque lui-même s'est bloqué en lecture seule d'une manière ou d'une autre. Gestion des disques de Windows :

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

Ce qui me trouble vraiment, c'est Current Read-only State : Yes y Read-only : No .

Tentatives de solutions

Jusqu'à présent, j'ai essayé :

• Formater le disque dans Windows (dans la gestion des disques, les options de formatage sont grisées lorsque vous cliquez avec le bouton droit de la souris).

• 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.

  Il n'y avait rien dans le journal des événements.

• Format de la ligne de commande Windows

  >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 : voir ci-dessous pour plus de détails

• Kubuntu fsck (via VirtualBox USB passthrough) : voir ci-dessous pour plus de détails

• Acronis True Image pour formater, convertir en GPT, détruire et reconstruire le MBR, en fait n'importe quoi : échec (impossible d'écrire sur le MBR).

Détails (et une belle histoire)

Contexte

Il s'agit d'une clé USB générique de 8 Go toute neuve avec laquelle je voulais créer une clé USB multiboot. Elle était formatée en FAT32, bien qu'étrangement un peu plus grande que la plupart des clés de 8 GIGAbytes que j'ai rencontrées. Environ 127 Mo étaient répertoriés comme "utilisés" par Windows. Je n'ai jamais su pourquoi. L'espace utilisable final correspondait à ce que j'attends normalement d'un disque de 8 Go (environ 7,4 GIBIbytes).

J'avais installé plusieurs distros Linux, ainsi qu'une copie de celle de Hiren. Elles démarraient toutes parfaitement. Elles ont été installées avec YUMI .

Lorsque j'ai essayé d'installer le DVD de Knoppix, YUMI a ajouté une option vidéo étrange à sa commande de démarrage, ce qui a provoqué le démarrage de Knoppix avec un écran noir sur X. tty Les interfaces 1 à 6 fonctionnent toujours comme des interfaces de texte uniquement.

Quelques jours plus tard, j'ai pris le temps de supprimer cette étrange option vidéo, afin que la commande de démarrage corresponde à celle fournie avec Knoppix. Lors de la tentative de démarrage, Knoppix a signalé une forme de corruption LZMA.

Jusqu'à la parution du présent numéro

J'ai pensé que les fichiers Knoppix avaient pu être corrompus d'une manière ou d'une autre, et j'ai donc essayé de le recharger. Le disque était presque plein (45 Mo libres), j'ai donc supprimé une ISO générique qui ne démarrait pas non plus. Tout s'est bien passé. J'ai ensuite utilisé YUMI pour "désinstaller" Knoppix, c'est-à-dire supprimer les fichiers et les menus. Les fichiers ont été supprimés en premier, puis les menus ont été effacés avec succès. Cependant, l'espace libre est resté bloqué à environ 700 Mo, comme avant la suppression de Knoppix. Dans l'ancien dossier Knoppix, il y avait un fichier de 0 octet nommé KNOPPIX qui n'ont pas pu être supprimées.

J'ai essayé de réinsérer le disque pour supprimer ce fichier - sans le retirer en toute sécurité, si cela faisait une différence (hé, il y a une première fois pour tout). En exécutant le programme standard de Windows chkdsk scanner sans /r o /f erreurs signalées trouvées. Exécution avec /r l'a juste bloqué.

J'ai décidé de donner fsck J'ai donc chargé ma VM Kubuntu et j'y ai connecté le disque avec la connexion USB 2.0 de VirtualBox. I umount ed it ( /dev/sda1 ) et a exécuté un fsck. There are differences between boot sector and its backup. J'ai choisi No action . Il m'a indiqué que les FAT différaient et m'a demandé de sélectionner le premier ou le deuxième FAT. Quel que soit mon choix, j'ai reçu une notification de Free cluster summary wrong . Si je choisis Correct il a donné une liste de noms de fichiers incorrects. Pour essayer de corriger quelque chose En tout cas, je l'ai fait fonctionner avec l'option -p option. À mi-chemin de la correction des fichiers, la VM s'est figée - j'ai mis fin à son processus environ dix minutes plus tard.

Cause ?

J'ai ensuite essayé d'utiliser YUMI, à nouveau, pour reconstruire l'ensemble du disque. J'ai utilisé l'option de reformatage intégrée de YUMI (en FAT32) et j'ai installé un ISO Kubuntu (700 Mo). Le formatage a réussi, mais l'extraction et la copie de Kubuntu (pour lesquelles YUMI utilise un binaire 7zip) se sont bloquées à environ 60 %. Après avoir attendu une quinzaine de minutes (plus longtemps que la dernière fois avec l'ISO Knoppix de 3,5 Go), j'ai sorti le disque. À ce stade, le disque était déjà formaté, SYSLINUX déjà installé, il ne restait plus qu'à déballer l'ISO et à modifier les menus de démarrage.

En le rebranchant, il s'est ouvert normalement, mais toute action d'écriture échouait. La gestion des disques l'a signalé comme étant en lecture seule. Lors de la reconnexion, il s'affichait normalement, mais une opération d'écriture le faisait repasser en lecture seule. Après quelques tentatives, il a commencé à s'afficher en lecture seule lors de l'insertion.

Tentatives de réparation

C'est à ce moment-là que j'ai effectué les tentatives énumérées ci-dessus pour essayer de le reformater en cas de formatage défectueux. Cependant, l'impossibilité de le faire, même sur un disque amorçable, indiquait que quelque chose de plus grave était en train de se produire. chkdsk déclare maintenant qu'il n'y a pas de problème, et fsck signale toujours des incohérences dans le MBR, mais choisit désormais automatiquement la première FAT après m'avoir dit que les FAT étaient différentes. Il fait toujours la même chose Free cluster summary wrong par la suite. Je ne peux pas courir avec -p car il est désormais marqué comme étant en lecture seule. Il a également réussi à corrompre le disque de ma VM lors de la première tentative (oui, je suis sûr d'avoir choisi sda, qui est mappé sur un disque de 7,4 Go - je ne suis pas sûr d'avoir choisi sda). triple vérifié). Dieu merci pour les instantanés ?

Je suis à court d'idées. Pour mon esprit inexpérimenté, il semble que quelque chose dans le firmware du lecteur l'ait configuré en lecture seule de manière "permanente" - y a-t-il un moyen de réinitialiser cela ? Je ne tiens pas particulièrement à conserver les données, étant donné que je l'ai reformaté deux fois.

De plus, les corrections qui me permettent de rester sous Windows sont préférables ; elles réduisent le risque que je détruise accidentellement mon disque dur principal.

Mise à jour 1 :

J'ai démonté le lecteur par curiosité.

Comme vous pouvez le constater, il n'y a pas de commutateurs de protection en écriture évidents. Il y a un circuit intégré de l'autre côté, de marque ALCOR, étiqueté AU6989HL, si cela a de l'importance. S'il ne semble pas y avoir de solution, je vais probablement retirer la carte (collée) et la mettre dans un lecteur de carte pour vérifier si c'est la carte ou le contrôleur qui a rendu l'âme.

Mise à jour 2 :

J'ai retiré la carte, Windows détecte maintenant le lecteur comme un lecteur de carte. Les contacts de la carte ne semblent pas être utilisés et il y a plusieurs rangées de trous sur la carte elle-même. En l'insérant dans le lecteur de cartes, on ne détecte qu'environ 30 Mo au total, en format RAW. Il s'agit probablement d'une erreur du lecteur d'origine qui signale la carte comme défectueuse (comme si la protection en écriture d'une vraie carte SD était activée) ou d'un mauvais contact quelque part.

Au moins, j'ai une carte Micro SD de 8GB de rechange maintenant... dès que j'aurai trouvé comment la formater en 8GB. Ce qui ne semble pas possible (Windows, Partedmagic, dd DBAN... non, toujours 30MB). Mais bon...

Mise à jour 3

J'en avais encore quelques-uns. Le deuxième a connu la même défaillance (lire seulement) aujourd'hui. Sur les autres, deux ont été détectés comme des lecteurs de cartes vides ou des lecteurs non formatés, en fonction de l'agitation (contact défectueux ?). L'un d'entre eux a été détecté comme étant rempli à un tiers et portait un nom de volume étrange.

H2testw results (on the last fully working one I have !):

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

Bien que cela soit un peu inquiétant, il est évident que les lecteurs ont en fait une capacité de près de 8 Go, comme l'a vérifié un outil souvent utilisé avec succès pour détecter les lecteurs flash falsifiés. L'utilisation d'une carte Micro SD plutôt que d'un module de mémoire flash marqué rend presque impossible le rechargement du disque, puisque les outils de rechargement d'Alcor attendent le modèle de mémoire comme paramètre. Je pense que je vais jeter le tout.