Twitter: @arieltorres | Ver perfil
No hay mejor detector de fallas que la impaciencia. La mía es aguda, por decirlo suavemente. Nada hay de filosófico en esto. Sólo vine mal de fábrica. No me instalaron el chip de espera, no consiguieron el driver para el adaptador de resignación o el programita SepaAguardar.exe no era compatible con mi sistema operativo, versión 1960.10.21. Me han dicho, y no me extraña, que ya era fastidioso desde pequeño con este tema de perder el tiempo esperando que maquinarias y servicios hicieran su trabajo.
En eso me encontraba desde hacía unas 48 horas con mi PC principal. El equipo, un Core 2 Duo, ya tiene su currículum, y sería fácil convertir cualquier achaque en una buena excusa para cambiarla. Pero no es mi estilo. Tanto como soy impaciente me gustan las cosas que duran. Por ejemplo, la máquina muleto, que ese día iba a sacar las papas del fuego, es un Pentium 4 a 3 GHz y ha estado funcionando sin pausa desde 2005. En esos seis años sólo le cambié la fuente de alimentación. Bien configurada, se porta de maravillas. Su función, además de la de paracaídas, es la de ripear los compactos que compro para pasarlos al iPhone, gracias a una lectora de CD que no hace prelectura de audio.
En fin, no me gustaba nada que a la PC que uso con más frecuencia se le diera por tomarse cierto tiempo para, por ejemplo, abrir el Firefox. Conmigo, no, maquinita , le dije. Pero lo volvió a hacer, sin escarmentar, y su letargo no hizo sino empeorar con las horas. Casi imperceptible, cierto, pero sabía que algo estaba pasando. Noté que el disco rígido estaba trabajando excesivamente para operaciones que no deberían llevarle sino un pestañeo.
Por si acaso, verifiqué que los backup estuvieran al día (son automáticos) y empecé por la menos mala de las posibilidades, es decir, que la cuenta de Windows, habiendo estado en funciones durante al menos dos años, se hubiera terminado por -cómo decirlo sin que suene a pseudociencia- dañar. Creé un usuario cero kilómetro y, ¡muy bien!, las pausas y demoras se evaporaron.
Noche de luto y de cierre
Sí, por un día. Así que la cuenta estaba OK.
Regresé a mi usuario de siempre y ejecuté un chequeo de disco. Tras una larga espera, Windows me informó que no había podido completar la operación. El rígido empezaba a acumular dedos acusadores. De ser el caso, sería una excepción. En muchos años he visto fallar sólo dos discos rígidos antes de reemplazarlos por otros más nuevos. Claro que las excepciones tienen la mala costumbre de acontecer.
Pasaron un par de días mientras las demoras cruzaban el sutil límite entre lo imperceptible y lo francamente irritante. El miércoles 5 a la noche, justo cuando llegaba a casa, una nueva teoría empezaba a cobrar forma en mi cabeza. Pensaba dedicarle un rato, pero en los siguientes minutos ocurrieron dos cosas casi simultáneas.
Primero, el equipo dejó de responder cuando abrí Firefox , mientras el rígido se deslomaba trabajando como si no hubiera un mañana. Lo dejé hacer durante unos 5 minutos (eso es mucho) y, cuando era obvio que se había colgado, puse fin a su sufrimiento apretando el botón de Reset . La máquina arrancó normalmente, pero Windows se negó a iniciarse con este bonito mensaje:
NTLDR not found
Entonces sonó el teléfono. Era Ricardo Sametband, que todavía estaba en la Redacción del diario, para darme la triste noticia de la muerte de Steve Jobs. Colgamos. Antes de que pudiera hablar con los editores del diario que llevarían adelante la cobertura, el teléfono volvió a sonar. Amigos informáticos, algunos muy acongojados, me estaban llamando por el mismo motivo. Todos entendieron que en ese momento no podía charlar y por fin pude conferenciar con los editores para armarme un plan de obra. Ya tenía hora de cierre, que es básicamente todo lo que un periodista necesita en circunstancias apremiantes.
Eso y una computadora, si no es mucho pedir.
¿Me estás cargando, NT?
El único problemita es que tenía por delante no mucho más de una hora para escribir, verificar y pulir, y la pantalla negra con el mensaje NTLDR not found no prometía cooperar.
Sabía cómo resolver esa falla, pero no había tiempo. Bueno, para eso están los muletos. La Pentium 4 haría honor a su robustez, o tendría que conformarme con escribir en la netbook, algo que prefería evitar.
Funcionó a la perfección y cuando entregué la nota ya eran como las 10 de la noche. Al día siguiente volvería tarde, lo mismo que el viernes. Sólo el sábado por la tarde me hice un rato para reparar el error de arranque.
NTLDR viene de NT Loader , es decir, cargador de Windows NT (XP, Vista y 7 son descendientes de NT). La pantalla negra me estaba diciendo que este componente no estaba disponible y la solución era restaurarlo. Había otra posibilidad, sin embargo: que el archivo de configuración del arranque de Windows ( boot.ini ) estuviera dañado. Pero, como siempre, preferí empezar por la menos mala de las posibilidades.
Primero copié los archivos faltantes ( NTLDR y ntdetect.com ) de un Windows sano a una llave de memoria. Luego arranqué el Core 2 Duo con un CD Live de Linux y, cuando tuve de nuevo la máquina en línea, traspasé los dos archivos del pendrive al disco duro. Reinicié y ahí estaba de nuevo XP funcionando.
No por mucho, sin embargo.
Te apuesto que son las memorias
El rendimiento del disco se estaba despeñando, literalmente. Como dije, tenía una teoría en mente. O dos. Pero para no verificar varias cosas a la vez, un error de procedimiento bastante común cuando tratamos de diagnosticar algo, seguí adelante con la idea de que el disco estaba fallando.
Hice un chequeo con corrección de errores, lo que me obligó a pasar un rato largo mirando la abundante lista de irregularidades arrojadas por chkdsk (Check Disk) . OK, era eso. Ahora todo marchará bien. El reinicio del otro día fue la causa de todo.
Pero me engañaba. El reinicio había sido consecuencia de un cuelgue generalizado, no su motivo. Además, si las computadoras acumularan tal cantidad de fallas lógicas en sus discos cada vez que apretamos Reset , entonces la informática no sería viable.
Era hora de salir de dudas. Busqué archivos grandes por un total de 10 o 12 GB y los copié del disco problemático a una unidad sana. El proceso llevó demasiado tiempo (evidencia A) y terminó con un error de chequeo de redundancia cíclica (evidencia B, señor juez). Lo que me llevaba como por un tobogán a la otra teoría: las memorias.
Ya me había pasado antes. La RAM es la mente de la computadora, todo pasa por ella, y cuando una mínima, microscópica celda se vuelve poco confiable, los errores se multiplican, lo mismo que su corrección, que consume mucho tiempo. Era el turno de MemTest86 ( www.memtest86.com ) , un excelente programa para verificar el estado de las memorias.
Estaba absolutamente convencido de que los errores iban a empezar a manchar de rojo la pacífica pantalla azul del Memtest86 . Me quedé mirando el monitor con aire de suficiencia y el ¡Lo sabía! listo para salir al aire.
Pero el test se ejecutó completo sin errores. Lo repetí. Nada. Cero. /dev/null.
Los dos módulos Kingston estaban como nuevos.
Anciano a los 3 años
Bueno, muchacho, estás rodeado, entrégate , le dije al disco rígido.
No tan rápido. Necesitaba pruebas. Usando la esforzada y fiel Pentium 4 fui al sitio del fabricante de la unidad (Western Digital) y bajé una versión actualizada del software de diagnóstico, la quemé en un CD y arranqué la PC en aprietos con él. Tuve la respuesta en algo así como 90 segundos. El código arrojado por el programa indicaba un error grave de Smart (siglas de Self Monitoring, Analysis, and Reporting Technology) ; en dos palabras, la unidad estaba condenada y había que reemplazarla.
Quedaba la remota posibilidad de que el cable o el slot SATA o el motherboard fueran los responsables; pero la alineación de la computadora respecto del eje galáctico tenía más chances de haber causado este error. No obstante, y para no quedarme con la duda, corrí el diagnóstico en otro slot, con otro cable y, finalmente, en la Pentium 4, es decir, en otro motherboard. No hubo cambios. La falla se repitió, inexorable. Luego corrí la utilidad de discos de Linux (en rigor, una interfaz gráfica para el comando hdparm) que también acusó errores de sectores pendientes de ser reasignados.
Les dejo una captura de pantalla. No parece nada demasiado grave, pero el error 197 de Smart es crítico e indica una falla inminente de la unidad ( http://kb.acronis.com/content/9133 ). El tiempo total de encendido del disco era de 2,7 años.
Bien, cosas que pasan. Había comprado ese disco en noviembre de 2008, y una cosa es ley en informática: los discos fallan, más tarde o más temprano. Normalmente, los descartamos antes de eso. Pero a este Western lo había castigado sin piedad durante casi 3 años, y mi impaciencia había descubierto la anomalía a tiempo para hacer un diagnóstico certero antes del colapso.
Eso sí, había elegido el peor momento para plantarse.
La marca nunca me había dado problemas, así que le aposté de nuevo. Compré un Caviar Black de 1 TB y las demoras desaparecieron..
No hay comentarios:
Publicar un comentario