lunes, 24 de agosto de 2009

Recuperar función de teclas muertas en Jaunty (y, en una de esas, resucitarlas)

Esta entrada es para describir como solucioné el problema de la función de una tecla en Ubuntu y contar cómo resolví la disfuncionalidad asociada a nivel de hardware.

La semana pasada me llevé una desagradable sorpresa cuando al intentar cambiar la opción del menú de Grub desde Winbugs (opción predeterminada) a Ubuntu, en cierto notebook, la tecla correspondiente no me respondía. Pensé que podía ser problema de arranque, así que reinicié. Pero el resultado fue el mismo: no funcionaba.

En primer lugar, intenté descartar un problema de software, así que entré a XP y la tecla seguía sin funcionar. En Ubuntu tampoco andaba ni en la bios. Por lo tanto, deduje que era altamente probable que fuera un fallo de hardware, así que me di la tarea de googlear para ver situaciones similares. No encontré nada. Al final contaré una hipótesis de por qué sucedió este desperfecto, pero antes describiré como solucioné el problema de la función de la famosa tecla.

La susodicha en cuestión es la "Up" o "arriba" y en Ubuntu la usaba para ubicarme dentro de los archivos, para moverme con facilidad en los textos en Evince, además de servirme para recordar los comandos en consola. La empecé a extrañar rápidamente. Al buscar sobre la temática de modificación del teclado encontré fácilmente una guía para cambiar el keymap (mapa de teclado), que era lo que deseaba hacer.

En el tutorial recomendaban el programa Xkeycaps que se encuentra en los repositorios de Ubuntu Jaunty, así que de inmediato se puede instalar con un "sudo apt-get install xkeycaps"o "sudo aptitude...". Luego de echarlo a andar, se elige el tipo de teclado (marca, tipo e idioma) y pronto aparece la imagen de un keyboard que debiera ser similar al que deseamos modificar. En la guía explican cómo replicar funciones de tecla y cambiar ciertos caracteres. En mi caso pensaba que podía servir la réplica de tecla...

Posterior a seguir la guía me di cuenta que no me funcionaba. El primer problema era que el teclado del notebook no se correspondía al de la imagen y las teclas tampoco (había algunas que no estaban en la imagen y viceversa). Hice varios intentos más y desistí de trabajar cómo me recomendaban en la página.

Empecé a revisar el archivo que creaba el programa al modificar el teclado: "/home/nombre_usuario/.xmodmap-nombredemaquina". El archivo en cuestión tenía la siguiente estructura: "keycode 0x43 = F1 XF86_Switch_VT_1 F1 XF86_Switch_VT_1 F1 XF86_Switch_VT_1" Primero está el código de la tecla, luego el nombre de función y códigos que desconozco.

Lo que realicé fue reemplazar está línea: "keycode 0x45 = F3 XF86_Switch_VT_3 F3 XF86_Switch_VT_3 F3 XF86_Switch_VT_3" por esta otra "keycode 0x45 = Up NoSymbol Up NoSymbol Up" Noten que mantuve el código de la tecla (0x45). En realidad está línea no estaba en el archivo, así que tuve que suponerla a partir de la línea de Left. Luego de realizar el cambio deseado, creo que es conveniente borrar las demás líneas (o comentarlas) por si generan algún cambio de función no deseado (recuerden que mi teclado no se correspondía al del programa).

Ahora cito la guía que ya mencioné:
Para que en los siguientes inicios de sesión se cargue el keymap modificado vamos a poner un comando en el bashrc o profile, según como te interese. Simplemente hay que ejecutar el programa xmodmap pasándole como parámetro la ruta del archivo.

Con permisos de root ejecutas el siguiente comando:

echo “xmodmap /home/alvaro/.xmodmap-flanders” >> /etc/profile

Con esto añadimos al final del archivo /etc/profile el comando. Recuerda cambiar mis datos por los tuyos. Así afectará a todos los usuarios pero si sólo quieres que te afecte a ti cambia /etc/profile por ~tusuario/.bash_profile

Y ya está, cuando vuelvas a iniciar sesión se cargará automáticamente el keymap modificado. (http://www.congdegnu.es/2008/12/28/cambiar-letras-del-teclado-personalizar-el-keymap-vaya/)

Al volver a entrar al escritorio de Gnome me apareció un menú. En realidad me preguntaba por cual de dos archivos deseaba usar. Elijan el que no termine en .bak (que es la copia de seguridad).

Antes de entrar al tema de hardware les daré un consejo para reconocer el keycode de determinada tecla. Pongan el cursor sobre la que quieren conocer el código. En la parte superior del programa, primera línea, aparecerá lo deseado.

Ahora comentaré sobre el hardware. Un amigo linuxero me contó que usualmente se le morían teclas. Decía que era por migas de pan que se atascaban. Lo encontré raro, pero probé usando una sopladora sobre el teclado del notebook. ¡Y funcionó! Así que si se les muere una tecla, ya saben.

Saludos

Leer más...

sábado, 15 de agosto de 2009

Restauración de particiones de unidades USB usando TestDisk

Mientras intentaba instalar alguna distro. poco exigente en recursos de RAM en mi viejo Notebook Presario 700, un error de visualización y tipeo (estaba trabajando sin ratón) me provocó la pérdida del formato de mi llave USB. Desde un error anterior similar, que me provocó perder varios gigas de información, había llevado cierta periodicidad de las copias de seguridad de esta llave (usando Partimage), pero lamentablemente había descuidado esta labor y el último backup accequible era de enero de este año. Desde esa fecha hasta ahora (varios meses), la cantidad de información que había sido agregada no era mucha, pero si bastante relevante (entre ellas un sitio completo del cual soy responsable).

Bueh, estuve revisando por Google sobre recuperación de particiones en pendrive usando Linux. No tenía la menor gana de instalar Winbugs para recuperar la tabla de particiones o los archivos. Luego de revisar varios blogs y páginas me encontré con la herramienta multiplataforma Testdisk, la cual está disponible en los repositorios de Ubuntu Jaunty (9.04). Posterior a varias horas (madrugué para esta labor) felizmente logré recuperar la tabla de particiones.

El resto del post es para explicar el procedimiento que realicé. Como recomendación (bien repetida, pero muy poco seguida) hagan copias de seguridad continuas de sus datos sensibles. Si no es un mal tecleado, puede ser un virus...

Primero les describiré el error que produjo este fallo. Luego haré una réplica de cómo fui aproximando a la solución del problema. Finalmente, redactaré la solución.

1. Se estaba usando un live-cd de System Rescue (distro. que se usa para rescatar sistemas, como su nombre lo indica, es decir, tiene herramientas de formateo, recuperación de datos, particiones, cifrado...). La estaba usando para formatear el disco duro de un Presario 700 y crear una tabla de particiones ad hoc para la nueva instalación de sistema operativo. El primer problema es que esta versión de System Rescue no me detecta bien el ratón, así que tuve que trabajar a puro atajo de teclado. En consola abrí Gparted (figura de la izquierda). El sistema tiene dos discos detectados: el disco duro (sda) y la llave usb (sdb). En la captura de pantalla se puede ver que en la zona superior derecha del programa se ubican las particiones (en la imagen aparece sda). La primera tarea pendiente era formatear sda, cuestión que hice. Sin embargo, en la pantalla me apareció otro disco sin formatear (sdb), y pensando que no había sido correctamente terminado el formateado anterior, puse borrar partición. A los instantes, supe que el tamaño era diferente (lamentablemente ambos discos estaban formateados usando fat32, lo cual hacía más fácil la confusión)...

2. Lo primero que hice fue buscar en Google alguna solución para recuperar particiones. Existía bastante información sobre la herramienta Testdisk, la cual además es multiplataforma. Empecé a leer en el sitio de la aplicación, el cual está traducido al español en buena parte. No parecía tan difícil, así que me animé a bajarla. En el caso de Ubuntu Jaunty fue bastante fácil, tan sólo teclear en consola "apt-get install testdisk". Ya instalada, la lancé.

Seguí las instrucciones clásicas (una buena guía en inglés está en el sitio oficial de la aplicación). Crear log, seleccionar disco a recuperar partición, elegir el tipo de la tabla de partición (Intel en mi caso) y Analize. Un primer error que detecté fue la siguiente línea luego del primer análisis "Partition sector doesn't have the endmark 0xAA55". Pienso que este error se debe a que no sólo borré una partición, sino la tabla de partición completa, por lo que el programa no es capaz de detectar en que punto se termina la partición. Luego elegí la realizar la búsqueda rápida ("Quick search") y luego la profunda ("Deeper search"). En este punto lo esperable y deseable es que salga una pantalla similar a esta, con una (o varias) partición marcada en verde (imagen de la derecha). En mi caso no aparecía ninguna partición. ¡Problema!

Luego de ello, seguí leyendo, buscando situaciones similares. En el apartado de "Ejemplos de recuperación" del sitio oficial de Testdisk planteaban que a veces existía un problema de geometría del disco. Cabezeras (heads), cilindros (cylinders) y sectors (sectores). Se supone que estos debían ser correctos y en caso de pérdida de la tabla de particiones, usualmente esta información era incorrecta. Se suponía que el programa señalaría lo que debía modificarse (ver imagen derecha y fijense en la hora... :P). En mi caso, debía modificar heads (de 255 a 16) y sectors (de 63 a 32). Esto se cambia en la sección geometry del menú posterior a la selección del tipo de tabla de partición. Fijense en seguir en ese orden sin cambiar ninguno de los otros valores, sino el disco queda de un tamaño distinto, pues los datos van acomodandose entre ellos.

Posteriormente, realicé un nuevo análisis (rápido y en profundidad) y, nuevamente, no llegué a la anhelada pantalla con línea verde. En este momento ya estaba bastante cansado. Se me ocurrió probar la técnica de recuperación con la llave, formateando nuevamente, ingresando un archivo y volviendo a borrar la tabla de partición. Antes de esta prueba tuve que realizar una copia clónica del pendrive. Para esto en Linux se usa el comando dd. (En concreto "dd if=origen of=destino". En el caso de mi llave fue "dd if=/dev/sdc of=/cualquier_directorio/nombrearchivo.img". Para restaurar la imagen se cambia el orden de las direcciones.) Seguí las instrucciones y logré restaurar la tabla de partición. :D Pero antes había un pequeño truco. Revise los datos de cabezas, sectores por pista y cilindros, por medio de Gparted luego de formatear con fat32. Los datos son los siguientes: cabezas (heads), 255; sectores por pista (sector for track), 63; cilindros (cylinders), 486. Al cambiar estos datos en la geometría del disco me recuperaba la partición. El dato clave era el de cilindros, en donde el programa me detectaba automáticamente 487.

En este punto estaba casi seguro de recuperar mi tabla de partición. Así que restauré la imagen clonada a mi llave, con lo que recuperé los datos sin poder ser visualizados. Ahora tenía, supuestamente, los datos para recuperar todo. Cuento corto: no funcionó. Pensé que podía deberse a que la tabla de partición era distinta a la que correspondía a los datos. Así que intenté recuperar mi backup de enero para poder recrear una tabla con una geometría parecida. No pude restaurar backup. Volví a formatear.

3. Luego de volver a formatear intenté nuevamente con Diskpart, sin grandes esperanzas (eran cerca de las 7 de la mañana). Cambié la geometría a la arriba mencionada. Hice búsqueda superficial y luego profunda. Y... ¡APARECIÓ LA LÍNEA VERDE! :D Bueh, luego restauré un par de elementos (opciones intuitivas en el menú) y listeé los archivos. Reconocí muchos de mis archivos. Puse escribir la tabla de partición (opción W) y al reiniciar el pendrive estaba todo como yo lo recordaba. :D!!

Y esa fue la solución. He pensado que la diferencia entre las dos últimos intentos está en la búsqueda profunda, que no recuerdo claramente haberla realizado la primera vez (con el sueño y el cansancio).

Eso sería.

Saludos
Leer más...