Jugando con la carga de módulos del kernel: rtc y rtc_cmos

Desde hace un tiempo vengo observando que al arrancar el sistema se trata de iniciar el servicio mplayer, devolviendo un error:

MPlayer: loading module rtc
FATAL: Error inserting rtc (/lib/modules/2.6.22-2-k7/kernel/drivers/char/rtc.ko): Input/output error Failed! ....
creating /dev/rtc, Error! cannot find /proc interface for max-us er-freq.

Investigando un poco parece que trata de cargar el módulo rtc y después hacer modificaciones en max-user-freq. Se supone que esto mejora la respuesta en tiempo real, cosa que beneficia a mplayer a la hora de reproducir el contenido multimedia sin saltos ni cortes.

El problema es el módulo rtc_cmos, que se carga antes de iniciarse el servicio mplayer. Este módulo impide la carga del módulo rtc por ser incompatibles (no pueden estar ambos cargados).

Tras iniciarse el sistema puedo descargar el módulo rtc_cmos mediante:

# rmmod rtc_cmos

Y cargar el módulo rtc:

# modprobe rtc

Tras esto, trato de iniciar el servicio mplayer, está vez con éxito:

/etc/init.d/mplayer start
MPlayer: raising max-user-freq of RTC from 64 to 1024

Efectivamente, parece tener un mejor comportamiento a la hora de reproducir vídeo y audio. Vamos a intentar hacer que cargue rtc al iniciarse el sistema.

modconf es un programa de Debian que permite configurar los módulos que se cargan al inicio. El módulo rtc_cmos (PC-style 'CMOS') se encuentra bajo la rama /kernel/drivers/rtc, y el módulo rtc (Enhanced Real Time Clock Support) se encuentra bajo la rama kernel/drivers/char.

Ninguno está seleccionado para ser cargado. Si selecciono rtc para ser cargado falla la carga por que durante el arranque se carga antes rtc_cmos.

Bien, probemos otra cosa. El fichero /etc/modprobe.d/blacklist contiene una lista de módulos que no se deben cargar. Se puede poner ahí el módulo rtc_cmos a ver si evitamos su carga. Pero en dicho archivo pone:

# This file lists modules which will not be loaded as the result of
# alias expansion, with the purpose of preventing the hotplug subsystem
# to load them. It does not affect autoloading of modules by the kernel.
# This file is provided by the udev package.

Mala pinta, no creo que funcione... y efectivamente no funciona.

Última solución, el fichero /etc/rc.local. Este fichero se ejecuta al final del arranque multiusuario y sirve para especificar órdenes que se quieran ejecutar al final del arranque (se entiende que para hacer algún ajuste fino del sistema). No me gusta mucho, pero ahí se pueden añadir las siguientes líneas:

rmmod rtc_cmos
modprobe rtc
/etc/init.d/mplayer start

Así se descarga el módulo rtc_cmos, se carga el módulo rtc y se inicia el servicio mplayer que modifica el max-user-freq de 64 a 1024 y que aparentemente mejora la respuesta en tiempo real (esperemos que no provoque otros efectos no deseados).

Copias de seguridad con Rsync

Actualmente se guarda demasiada información en los ordenadores personales como para arriesgarse a una pérdida de datos debido a un falló del disco duro, subidas de tensión y otros desastres varios.

Es posible ir haciendo copias de seguridad en DVD, pero es lento, tedioso, y los DVD son ya algo pequeños comparado con la capacidad de los discos duros. Además, la durabilidad de un DVD no está especialmente asegurada. Personalmente, creo que es un medio muy poco fiable.

También es posible usar RAID, pero es quizá una solución no demasiado adecuada para este problema. Ciertas configuraciones de RAID permiten tener dos discos duros con la información duplicada en ambos de forma transparente al usuario. Sin embargo, exige dos discos duros iguales, copia toda la información sin posibilidad de discriminar la que es interesante de la que no, y además puede tener ciertos efectos secundarios no deseados (la velocidad de escritura puede ralentizarse, aunque bien es cierto a cambio puede incrementar la velocidad de lectura). También hay que tener en cuenta que mediante RAID un error humano o de software que borre o sobreescriba datos y ficheros no es recuperable ya que el sistema operativo se encargará transparentemente de hacerlo en ambos discos duros a la vez.

La solución escogida aquí es hacer una copia de seguridad mediante rsync a otro disco duro. Rsync se encarga de hacer el trabajo sucio de copiar el contenido de los datos originales a la copia de seguridad. Es inteligente, por lo que sólo copia los ficheros que han sido alterados y es capaz de enviar solamente aquellas partes de cada ficehro que han sido modificadas, ahorrando mucho tiempo, especialmente si la copia se hace a través de la red.

En Kriptópolis hay un excelente artículo al respecto que permite realizar cuatro copias incrementales al día más una completa, guardando las 3 últimas copias de seguridad. Dado que ahí esta muy explicado el asunto de hacer copias de seguridad en local, me centraré en la copia vía red.

Opciones rápidas de rsync:

• a: copiar para archivar. Es un atajo que combina otras opciones que básicamente produce que se haga una copia exacta (archivos, enlazes simbólicos, permisos, etc).
• v: indica que se debe mostrar información de la ejecución (el conocido modo verboso).
• z: comprime los datos antes de enviarlos al destino (sólo es realmente útil en copias vía red).
• e rsh: sirve para transmitir los datos vía red por ssh.
• n: ejecución de prueba, muestra lo que haría pero realmente no hace nada.
• exclude-from=FICHERO: se deben excluir los directorios y rutas contenidos en el fichero indicado (se pueden usar caracteres comodín).

Así, para realizar una copia remota se debería usar el comando:

rsync -e ssh -azv ORIGEN DESTINO

Suponiendo, como yo, que se quiera copiar el directorio del usuario pepe de un sistema a un directorio de copias de seguridad del servidor llamado Sancho, el comando sería:

rsync -e ssh -azv /home/pepe sancho:/var/backups/pepe

Dado que estamos accediendo a un sistema remoto se debe tener permiso para acceder a dicho sistema. En principio (imagino) se pedirá usuario y contraseña. Dado que se pretende automatizar la tarea lo suyo es configurar una autentificación mediante clave privada/clave pública tal y como permite SSH.


Nota: Comentarios cerrados debido a la continua avalancha de spam chino en esta y solo en esta entrada. Misterios de internet.