Reparando paquetes de software en una distribución Linux basada en RPM

En Linux en ocasiones las cosas simplemente empiezan a funcionar mal y, a no ser que se alineen los astros, recuperar un archivo o una configuración al estado en el que estaban las cosas antes de romperse se vuelve misión imposible. En estos casos a veces lo más fácil es revertir el componente de software que falla al estado original y volver a reconfigurarlo de nuevo.

El problema que puede aparecer en este punto es que o no sabemos que es exactamente lo que se ha roto o simplemente no sabemos a que paquete pertenece el archivo que se queremos reinstalar. Para ello viene en nuestra ayuda dos opciones de RPM tremendamente útiles.

¿Qué se ha estropeado?

Imaginemos que leyendo a través de un log o de cualquier otra manera hemos averiguado que el problema está involucrado de alguna manera con la librería /usr/lib/awt-gen-aas/12345-2345-libAsd.so. El problema es que con un nombre como ese no tenemos manera de saber a que paquete pertenece. Para solucionar esto podemos hacer una query rpm sobre el archivo para conocer a que paquete pertenece de la siguiente manera, pudiéndonos devolver algo parecido a los siguiente:

[machine@user ~]$ rpm -qf /usr/lib/awt-gen-aas/12345-2345-libAsd.so
rhythmbox-2.90.1-17.git20110927.fc16.x86_64
[machine@user ~]$ _

Por fin sabemos que el paquete que falla es rhythmbox-2.90.1-17.git20110927.fc16.x86_64, que es Rhythmbox. La opción -q o --query especifica que queremos imprimir información sobre un paquete RPM y la opción -f o --file que queremos que se haga sobre un archivo

El comportamiento por defecto es imprimir el nombre del paquete consultado, pero puede configurarse la cadena de salida en base a muchísimas opciones con la opción ----queryformat.

¿Por qué se ha roto?

Una vez localizado el paquete conflictivo, estamos un pasito más cerca de solucionar el problema. Quizás antes de reinstalar todo el paquete nos puede interesar comprobar qué es exactamente lo que se ha estropeado por si tuviese fácil solución. En ocasiones, por ejemplo, el error puede deberse a un archivo que cambió de privilegios o que cambio de usuario o grupo, en cuyo caso la solución es bastante sencilla.

Vamos entonces usar la opción -V de RPM para comprobar si algún elemento del paquete rhythmbox-2.90.1-17.git20110927.fc16.x86_64 está fallando. Algo parecido a lo siguiente podría salir:

[machine@user ~]$ rpm -V 'rhythmbox-2.90.1-17.git20110927.fc16.x86_64'
S........  c /etc/rhythmboc.conf
.M.......  d /usr/share/doc/rhythmbox-2.90.1/help
..5......  g /var/log/rhythmbox.log
...D.....  l /usr/share/doc/rhythmbox-2.90.1/LICENSE
....L....  r /usr/share/doc/rhythmbox-2.90.1/README
.....UG..    /usr/share/rhythmbox/library1.so
.......T.    /usr/share/rhythmbox/library2.so
........P    /usr/share/rhythmbox/library3.so
SM5DLUGTP    /usr/share/rhythmbox/library4.so
missing      /usr/share/rhythmbox/library5.so
[machine@user ~]$ _

La opción -V o --verify comprueba el paquete comparando los archivos de éste cuando estaba recién instalado con el estado de los archivos actualmente en busca de diferencias. Aquellos archivos con conflictos potenciales son mostrados y el resto ignorados

La información se muestra en tres columas:

• La primera columna es un conjunto de 0 a 9 caracteres que señalan las divergencias con el archivo original encontradas. Sus significados son:
  • S: difiere el tamaño del archivo con respecto al original
  • M: difieren los permisos de acceso al archivo con respecto al original
  • 5: difiere la suma de verificación MD5 con respecto al original
  • D: difieren los números mayor y menor del dispositivo/driver con respecto al original
  • L: difiere la ruta del enlace simbólico relacionado al archivo original
  • U: difiere el usuario propietario del archivo con respecto al original
  • G: difiere el grupo propietario del archivo con respecto al original
  • T: la fecha de modificación del archivo con respecto al original
  • P: difiere alguna de las dependencias dependencias del archivo con respecto al original
  • missing: el archivo ha desaparecido del sistema de archivos
• La siguiente columna nos informa de qué tipo fue marcado el archivo en el paquete original, las opciones son:
  • vacío: el archivo es un fichero regular
  • c: el archivo es un fichero de configuración
  • g: el archivo es in fichero fantasma o ghost, esto es, pertenecen al paquete pero no venían en este o estaban destinado a ser modificados. Un ejemplo de este tipo de archivos son los ficheros de log
  • l: el archivo es un fichero de texto con el contenido de la licencia
  • r: el archivo es un fichero de texto con el README del paquete

Existe también una opción muy interesante para extender la acción de la mayoría de los comandos de RPM a todos los paquetes instalados con el modificador -a. Esto nos permite hacer cosas tan molonas como obtener todos los archivos de todos los paquetes que tienen algun problema específico usando grep. Por ejemplo, podemos obtener todos archivos de todos los paquetes del sistema que fallan en la suma md5 con el siguiente comando:

[machine@user ~]$ rpm -Va|grep ^..5

Vale, ¡Pero esto sigue sin funcionar!

Hemos revisado todos los ficheros a conciencia, nos hemos hartado y hemos decidido reinstalar el paquete entero. Tenemos varias alternativas para borrar los paquetes o reinstalarlos automáticamente dependiendo de la distribución, pero la opción multiplataforma es usando el modificador -e de rpm:

[machine@user ~]$ rpm -e 'rhythmbox-2.90.1-17.git20110927.fc16.x86_64'

El modificador -e desinstala un paquete de manera segura, hasta aquí nada del otro mundo. Lo interesante del funcionamiento de esta opción es que los archivos de configuración que desde la instalación del paquete fueron modificados no serán borrados, sino que seran renombrados en el mismo directorio con las extensiones .rpmorig, .rpmsave o similar. De esta manera, cuando reinstalemos de nuevo el paquete con nuestro sistema de gestión de repositorios preferido tendremos tanto el archivo antiguo como el nuevo para realizar la instalación.

El último paso es instalar el paquete de nuevo. Si lo hacemos desde un archivo .rpm, sería tan sencillo como lo que sigue:

[machine@user ~]$ rpm -i 'rhythmbox-2.90.1-17.git20110927.fc16.x86_64.rpm'

O en Fedora desde repositorios:

[machine@user ~]$ yum install 'rhythmbox-2.90.1-17.git20110927.fc16.x86_64'