Linux Disks: Rescatando data de un disco de portátil VIT de las garras de la muerte

Mil disculpas por tener abandonado el blog!, ciertamente el no tener portátil y trabajar con portátil prestada, me limita en las cosas que podría y/o debería hacer en el equipo, además el trabajo, múltiples ocupaciones hacen imposible dedicarle mucho tiempo a escribir …

Pero sucedió algo …😉

Me encontraba usando una portátil VIT (modelo 2400), en vista que mi anterior portátil Thinkpad fue robada en diciembre pasado, con el equipo todo iba bien salvo algunas cosas:

  • Ligeros congelamientos en el mousepad
  • Keycodes disparados (visibles en el dmesg) sin haber presionado ninguna tecla especial
  • Algunos problemas con la red
  • Incompatibilidad con Debian Jessie e imposibilidad de usar un kernel liquorix con la tarjeta inalámbrica que trae.

Bueno, todo iba bien con el equipo, hasta que un día, de improviso y sin siquiera avisarlo el smartctl, el disco duro se congeló!, el equipo literalmente se congeló por completo, una larga espera y tuve que apagarlo forzado.

Al encender, veo que insólitamente el BIOS ni siquiera ve el disco!, es decir, el disco duro se ha “esfumado”, tratando de “dilucidar” tan extraño comportamiento de la BIOS (imaginándola tal vez desactualizada y jamás dudando de un disco duro SATA3 de menos de un mes de uso), decido probar suerte y meto un Live-USB de Debian Installer.

Pero, por si acaso, presiono “TAB” para editar la entrada del “Advanced Options > Rescue Mode” y escribo:

idebus=66 pci=routeirq

La primera opción, hace que el disco funcione como un IDE-66 (PATA-compatible) y la segunda opción cuestiona la decisión de asignación de IRQ de la tarjeta madre y decide que el kernel la haga por si mismo (esto me permite en algunas tarjetas madre “buggy”, como la que usan en VIT, detectar hardware con problemas).

Insólito!, el disco aparece en el dmesg!

[ 2377.833672] end_request: I/O error, dev sdb, sector 4007
[ 2377.833689] sd 9:0:0:0: [sdb] Unhandled error code
[ 2377.833695] sd 9:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 2377.833708] sd 9:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 0f a7 00 00 08 00
[ 2377.833745] end_request: I/O error, dev sdb, sector 4007
[ 2377.833767] sd 9:0:0:0: [sdb] Unhandled error code
[ 2377.833774] sd 9:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 2377.833784] sd 9:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 0f a7 00 00 08 00
[ 2377.833820] end_request: I/O error, dev sdb, sector 4007
[ 2414.775081] sd 9:0:0:0: [sdb] Unhandled error code
[ 2414.775083] sd 9:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 2414.775086] sd 9:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 00 41 00 00 02 00

Ahora bien,eso realmente no significa mucho, el disco da problemas de montaje, sin embargo, el DRIVER_OK me causa sospechas, ¿y si el disco está bueno, pero la lógica de comunicación de la tarjeta madre está operando mal?, entonces apago el equipo y reinicio el sistema de rescate, pero esta vez con dos opciones más:

libata.force=noncq libata.atapi_passthru16=0 idebus=66

Con la primera opción, fuerzo la desactivación del NCQ, es un sistema de cola de comandos de 32bits que utilizan los discos SATA y SSD más modernos para comunicarse con la tarjeta madre, un error en la lectura de comandos por parte de la controladora ATA puede “simular” un fallo de hardware y desactivar el disco; por ende, desactivar el NCQ puede ayudar a la controladora SATA a entender al disco duro.

La segunda opción, me permite tratar al disco como si fuera un viejo IDE, desactivando el soporte a comandos de 16 bits.

Con estas dos opciones, mágicamente el disco duro ahora es perfectamente detectado, he montado un disco externo, rescaté los datos a dicho disco externo y listo!, datos del disco duro “dado por muerto” rescatados.

¿y qué pasará con la portátil?

Aunque pudiera desactivar el modo AHCI en el BIOS y funcionar en modo IDE y pudiera luego pasar estas opciones en el GRUB, ciertamente estas opciones hacen que el disco vaya a muchísima menos velocidad que en condiciones normales, cómo la única posible solución documentada es una actualización del BIOS que le permita actualizar la tabla APCI y corregir el bug NCQ de la controladora ATA; será mejor devolver el equipo ya que al ser un equipo VIT ensamblado en Venezuela con piezas chinas, es poco probable que el proveedor de piezas de VIT haya sacado alguna “actualización de seguridad” del BIOS VIT.

Si a alguno le quedó el disco como “desaparecido del BIOS” en una VIT y necesitan con urgencia sacar unos datos, les indico que esta es la solución de resurrección más idónea.

Si alguien sabe como “actualizar” el BIOS de una VIT, me avisa …

Actualización

Luego de “despertar” al disco con “idebus=66 libata.force=noncq” y apagar inmediatamente el equipo, EL EQUIPO ENCENDIÓ!, normalmente, salvo que al llegar al GRUB, por precaución agregué ámbas opciones (idebus=66, libata.force=noncq) y pude llegar al GNOME para sacar sin apuro y con más vigilancia (y con un entorno gráfico) algunas cosas que no había respaldado.

Happy Hacking!

Acerca de phenobarbital

http://about.me/phenobarbital

Publicado el 24 febrero 2014 en Blogeando!, Cultura Libre, La nota del día, PlanetaLinux, Software Libre y etiquetado en , , , , , , , , , , , , . Guarda el enlace permanente. 1 comentario.

  1. donde descubriste la info: “Con la primera opción, fuerzo la desactivación del NCQ…… por parte de la controladora ATA puede “simular” un fallo de hardware y desactivar el disco; por ende, desactivar el NCQ puede ayudar a la controladora SATA a entender al disco duro”
    las otrs opciones en kernels viejos era 33 en vez de 66 que 66 ya asume DMA..

    veindo la opcion libata.atapi_passthru16=0 en mi kernel no activa ese modo 16 bits si lo realizo manual con hdparm.. sale error en ata al realizarlo.. pero en el info sale activado.. esto desde que tengo uso de linux.. lo otro nunca he visto que el hdparm informe velocidades de mas de 66, por eso mi intres de donde sacste dichas conclusiones..

    ah por cierto, el CNSL esta oficilmente politizdo al 100% octavio ya debe estar 100% atornillado, solo vr los temas de la sede caracas es suficiente para saber que ya no se ira mas nunca..

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: