¿Por qué mi unidad flash se convirtió en "sólo lectura" y (cómo) puedo solucionarlo?
Tengo un pendrive nuevo (de una semana de antigüedad) que ha quedado marcado como de sólo lectura, por Windows, Kubuntu y un particionador de arranque. ¿Por qué ha ocurrido esto? ¿Se puede arreglar? Si lo es, ¿cómo puedo arreglar esto?
- *
El problema
En primer lugar, esta unidad es nueva. Ciertamente no se ha utilizado lo suficiente como para morir por el desgaste normal, aunque no descartaría componentes defectuosos.
La propia unidad se ha bloqueado de alguna manera en un estado de sólo lectura. Gestión de discos de 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
Lo que realmente me confunde es Current Read-only State : Yes
y Read-only : No
.
Soluciones intentadas
Hasta ahora, he probado:
Formatearla en Windows (en la gestión de discos, las opciones de formato aparecen en gris al hacer clic con el botón derecho).
DiskPart Clean (
CLEAN - Clear the configuration information, or all information, off the disk.
):Formateo en la línea de comandos de Windows
Windows chkdsk: ver más abajo para más detalles
Kubuntu fsck (a través de VirtualBox USB passthrough): ver más abajo para más detalles
Acronis True Image para formatear, para convertir a GPT, para destruir y reconstruir MBR, básicamente cualquier cosa: falló (no pudo escribir en el MBR)
Detalles (y una bonita historia)
Antecedentes
Este era un pendrive genérico de 8GB nuevo con el que quería crear un pendrive multiarranque. Venía formateado como FAT32, aunque extrañamente un poco más grande que la mayoría de las unidades flash de 8 GIGAbytes que he encontrado. Aproximadamente 127MB fueron listados como “usados” por Windows. Nunca descubrí por qué. El espacio final utilizable era más o menos lo que normalmente espero de una unidad de 8 GB (aproximadamente 7,4 GIBIbytes).
Había puesto unas cuantas distros de Linux, junto con una copia de Hiren. Todas arrancaban perfectamente. Se pusieron con YUMI .
Cuando intenté poner el DVD de Knoppix, YUMI añadió una extraña opción de vídeo a su comando de arranque que hizo que Knoppix arrancara con una pantalla negra en X. tty
s 1 a 6 todavía funcionaban como interfaces de sólo texto.
Unos días más tarde, me tomé un tiempo para quitar esa extraña opción de vídeo, haciendo que el comando de arranque coincidiera con el que viene con Knoppix. Al intentar arrancar, Knoppix reportó alguna forma de corrupción LZMA.
Llevando al problema actual
Pensé que los archivos de Knoppix podrían haberse corrompido de alguna manera, así que intenté recargarlo. El disco estaba casi lleno (45MB libres), así que borré una ISO genérica que tampoco arrancaba. Eso fue bien. Luego pasé por YUMI para ‘desinstalar’ Knoppix, es decir, eliminar los archivos y quitar de los menús. Los archivos fueron primero, luego los menús se borraron con éxito. Sin embargo, el espacio libre se quedó estancado en unos 700MB, igual que antes de eliminar Knoppix. En la antigua carpeta de Knoppix, había un archivo de 0 bytes llamado KNOPPIX
que no se podía borrar.
Intenté reinsertar el disco para borrar este archivo - sin quitarlo de forma segura, si es que eso hizo alguna diferencia (hey, la primera vez para todo). Ejecutando el escaneo estándar de Windows chkdsk
sin /r
o /f
reportó errores encontrados. Ejecutando con /r
sólo se atascó.
Decidí darle una oportunidad al fsck
, así que cargué mi VM de Kubuntu y conecté el disco a ella con el USB 2.0 passthrough de VirtualBox. Lo puse a umount
(/dev/sda1
) y ejecuté un fsck. There are differences between boot sector and its backup.
elegí No action
. Me dijo que las FAT son diferentes y me pidió que seleccionara la primera o la segunda FAT. Sea cual sea la que seleccioné, recibí un aviso de Free cluster summary wrong
. Si elegía Correct
, me daba una lista de nombres de archivos incorrectos. Para intentar arreglar algo, al menos, lo ejecuté con la opción -p
. A mitad de camino de arreglar los archivos, la VM se congeló - terminé su proceso unos diez minutos después.
¿Causa?
Mi siguiente intento fue utilizar YUMI, de nuevo, para reconstruir todo el disco. Utilicé la opción de reformateo de YUMI (a FAT32) e instalé una ISO de Kubuntu (700MB). El formato fue exitoso, sin embargo, el extracto y la copia de Kubuntu (que YUMI utiliza un binario 7zip para) se congeló en alrededor del 60%. Después de esperar unos quince minutos (más de lo que tardó la ISO de Knoppix de 3,5 GB la última vez), saqué la unidad. La unidad en este punto ya estaba formateada, SYSLINUX ya instalado, sólo esperando el desempaquetado de una ISO y la modificación de los menús de arranque.
Al conectarlo de nuevo, se encendió con normalidad - sin embargo, cualquier acción de escritura fallaba. La administración de discos lo reportó como de sólo lectura. Al volver a conectarlo, aparecía con normalidad, pero una operación de escritura hacía que volviera a ser de sólo lectura. Después de algunos intentos, empezó a aparecer como sólo lectura al insertarlo.
Intentos de arreglar
Aquí es cuando hice los intentos listados arriba, para tratar de reformatearla en caso de un formato defectuoso. Sin embargo, la incapacidad de hacerlo, incluso en un disco de arranque, indica que algo más grave está mal. chkdsk
ahora informa de que no hay nada malo, y fsck
sigue informando de inconsistencias en el MBR, pero ahora siempre elige la primera FAT automáticamente después de decirme que las FAT son diferentes. Sigue haciendo lo mismo Free cluster summary wrong
después. Ya no puedo ejecutar con -p
porque ahora está marcado como de sólo lectura. También ha conseguido corrompió el disco de mi VM de alguna manera en el primer intento (sí, estoy seguro de que elegí sda, que está asignada a una unidad de 7,4GB - lo he triple comprobado). Gracias a Dios por las instantáneas…
- *
Me he quedado sin ideas. Para mi mente inexperta, parece que algo en el firmware de la unidad la ha configurado como de sólo lectura “permanente” de alguna manera - ¿hay alguna manera de restablecer esto? No me importa especialmente conservar los datos, teniendo en cuenta que lo he reformateado dos veces.
Además, los arreglos que me mantienen en Windows son mejores; reduce el riesgo de que accidentalmente destruya mi disco duro principal.
- *
Actualización 1:
Desmonté el disco por curiosidad.
Como puedes ver, no hay interruptores de protección contra escritura obvios. Hay un IC en el otro lado, marca ALCOR etiquetado AU6989HL, si eso importa. Si parece que no hay forma de arreglar esto, probablemente sacaré la tarjeta (pegada) y la pondré en un lector de tarjetas para comprobar si es la tarjeta o el controlador el que ha muerto.
- *
Actualización 2:
He sacado la tarjeta, Windows detecta la unidad como un lector de tarjetas ahora. Los contactos de la tarjeta no parecen estar usados, y hay varias filas de agujeros en la propia tarjeta. Al ponerla en el lector de tarjetas sólo detecta unos 30MB en total, RAW. Probablemente sea la unidad original la que informa incorrectamente de que la tarjeta está defectuosa (como si la protección contra escritura de una tarjeta SD real estuviera activada) o un contacto defectuoso en alguna parte.
Si no es así, ahora tengo una tarjeta Micro SD de 8GB de repuesto… en cuanto descubra cómo formatearla como 8GB. Lo cual no parece posible (Windows, Partedmagic, dd
, DBAN… nope, todavía 30MB). Ah, bueno.
- *
Actualización 3
Tuve algunos más de estos. El segundo falló de forma similar (sólo lectura) hoy. De los restantes, dos fueron detectados como lectores de tarjetas vacíos/unidades sin formatear, dependiendo de la agitación (¿contacto defectuoso?). Uno fue detectado como 1/3 lleno, y tenía un nombre de volumen extraño.
H2testw resultados (¡en la última que tengo que funciona completamente!):
Aunque esto es un poco preocupante, evidentemente las unidades tienen realmente una capacidad cercana a los 8GB, como se ha verificado con una herramienta que se utiliza a menudo con éxito para detectar unidades flash falsas. El uso de una tarjeta Micro SD en lugar de un módulo de memoria flash marcado hace casi imposible reflashear la unidad, ya que las herramientas de flasheo de unidades de Alcor esperan el modelo de memoria como parámetro. Creo que voy a tirar todo el lote.