Guía udev en GentooCuando los usuarios de Linux hablan acerca del hardware de sus sistemas a gente que puede llegar a pensar que Linux es algún tipo de virus o marca de café, el uso de términos como "barra dev barra algo" provocará, sin dudas, miradas raras. Pero para el usuario afortunado (incluyendo al lector) el usar /dev/sda1 es solo una forma rápida de explicar que nos referimos a la primera partición del disco primer disco SATA. ¿O no? Todos sabemos lo que es un archivo de dispositivo. Algunos incluso saben por qué cuando miramos un poco más de cerca la salida de ls -l en /dev los archivos de dispositivo muestran unos números especiales. Pero lo que siempre damos por sentado es que el primer disco SATA se llama /dev/sda. Tal vez no lo vea así, pero ésta es un fallo de diseño. Piense en los dispositivos que se enchufan en caliente como los USB, IEEE 1394, tarjetas PCI que se cambian en caliente ... ¿Cuál es el primer dispositivo? ¿Y por cuánto tiempo? ¿Cómo se llamarán los demás dispositivos cuando el primero desaparezca? ¿Cómo afectará ésto a las transacciones en curso? ¿No sería gracioso que un trabajo de impresión se cambiase de repente desde su flamante impresora láser nueva a la moribunda impresora de matriz solo porque alguien decidió desenchufar la impresora láser que era la primera impresora? Entra en escena udev. Los objetivos del proyecto udev son a la vez interesantes y necesarios:
Cada vez que se produce un cambio en la estructura de dispositivos, el núcleo emite un uevent el cual es recogido por udev. Entonces, udev sigue las reglas declaradas en los directorios /etc/udev/rules.d y +/lib/udev/rules.d. Basándose en la información contenida en el evento, busca la regla o reglas que necesita ejecutar y realiza las acciones requeridas. Estas acciones pueden consistir en la creación o eliminación de ficheros de dispositivo, pero pueden suponer también la carga de ficheros de firmware particulares en la memoria del núcleo. Udev está pensado para ser utilizado en combinación con un núcleo 2.6 (como gentoo-sources con el perfil por defecto 10.0). Si está usando alguno de estos núcleos, no debería tener problemas, ya que el soporte necesario está incluido en todas las versiones estables de sys-apps/baselayout. Normalmente, udev debería estar instalado en su sistema, pero si éste no es el caso, es fácil de instalar:
Al construir un núcleo, asegúrese de activar las siguientes opciones:
Si usa genkernel, no necesita hacer nada especial. Genkernel activa udev por defecto. Nodos de dispositivos que faltan al arrancar Si no logra arrancar por culpa de errores acerca de un /dev/null no encontrado, o porque falta la consola inicial, el problema es que faltan unos nodos de algunos dispositivos que deberían existir antes de montar /dev para luego sea manejado por udev. Esto es común en máquinas Gentoo que tienen instalaciones hechas con mucha antigüedad. Si tiene instalado sys-apps/baselayout-1.8.12 o más reciente, este problema está paliado, ya que el proceso de arranque debe poder completarse. Sin embargo, para deshacerse de esas advertencias molestas, debe crear los nodos faltantes como describimos más adelante. Para determinar cuáles nodos están presentes antes de montar el sistema de archivos /dev, ejecute las siguientes órdenes:
Los dispositivos necesarios para un arranque exitoso son /dev/null y /dev/console. Si no aparecen en el listado previo, debe crearlos manualmente. Escriba las siguientes órdenes dentro del directorio test/dev/:
Al terminar, no se olvide de desmontar el directorio test/:
Si usa el driver propietario de nvidia y el servidor X falla al iniciar en un sistema puramente udev, asegúrese de tener el módulo nvidia listado en /etc/conf.d/modules. Nombramiento inconsistente entre DevFS y udev Aunque nuestra intención es tener un esquema de nombramiento consistente para ambas soluciones dinámicas de manejo de dispositivos, a veces ocurren diferencias en el nombramiento. Un conflicto reportado ocurre con el controlador HP Smart Array 5i (para ser más preciso, con el módulo del núcleo cciss). Con udev los dispositivos son nombrados /dev/cciss/cXdYpZ con la X, Y y Z como números enteros. Con devfs, los dispositivos son nombrados /dev/hostX/targetY/partZ o enlazados simbólicamente a /dev/cciss/cXdY. Si este es el caso, no se olvide actualizar su archivo /etc/fstab y su archivo de configuración del gestor de arranque como corresponde. Lo mismo ocurre con los enlaces simbólicos que existían en el directorio /dev, como /dev/mouse, el cual udev ya no crea. Asegúrese de revisar su configuración X para ver si la regla del ratón apunta a un archivo de dispositivo existente. Otro problema es la diferencia en el nombramiento de los terminales entre devfs y udev. Aunque devfs denomina tty a sus terminales, udev por su parte los llama vc y tty. Esto podría resultar en un problema en caso de que esté restringiendo los ingresos del superusuario desde las consolas usando /etc/securetty. Tendrá que asegurarse que tty1 y vc/1 aparezcan listados en /etc/securetty para que el superusuario pueda ingresar usando la consola. Renombrar dispositivos de bloque Versiones más recientes de udev (104 y subsiguientes) conjuntamente con núcleos más recientes (2.6.19 y subsiguientes) podrían cambiar los nombre de los dispositivos de disco, debido a un cambio en la implementación de libata del núcleo. Un dispositivo CD-RW en /dev/hdc podría cambiar a /dev/sr0. Mientras que normalmente esto no es problema, podría causar dificultades para algunas aplicaciones que busquen los dispositivos en ubicaciones fijas. Por ejemplo, media-sound/rip espera encontrar los discos en /dev/cdrom, lo cual es un problema porque los núcleos nuevos, en conjunción con udev renombrarán este dispositivo a /dev/cdrom1. Para solucionar estos problemas, modifique el archivo /etc/udev/rules.d/70-persistent-cd.rules y asigne el nombre correcto al dispositivo. Para más información acerca de escribir reglas para udev, por favor lea la guía de Daniel Drake. A veces enchufar y enchufar de nuevo un dispositivo de red (cómo una tarjeta WiFi USB) puede renombrar su dispositivo de red cada vez, incrementando el número en uno. Cuando esto ocurra, puede ver que se nombran wlan0, wlan1, wlan2, etc. Esto es porque udev esta añadiendo reglas adicionales a su fichero de reglas, en lugar de recargar las reglas existentes. Ya que udev ve su directorio de reglas a través de inotify, necesitará soporte para inotify en su fichero de configuración del núcleo:
Ahora udev conservará los nombres apropiados para sus dispositivos de red. udev carga los módulos en orden impredecible A veces udev carga los módulos en un orden indeseado, impredecible o hasta aparentemente aleatorio. Esto es especialmente común en sistema con dispositivo múltiples del mismo tipo, al igual que dispositivos multimedia. Esto puede afectar los número de dispositivo asignados; por ejemplo, las tarjetas de sonido se cambian de número. Existen unas pocas soluciones para resolver la asignación de números de dispositivo y/o orden de carga de los módulos. Idealmente, podría pasar parámetros al módulo para especificar el número de dispositivo deseado. Algunos módulos, como los de ALSA, incluyen un parámetro tipo "índice". Los módulos que usen este parámetro pueden ser ajustados de esta manera. Este ejemplo es para un sistema con dos tarjetas de sonido. La tarjeta con el índice 0 es designada como la primera tarjeta. Una vez que los parámetros sean cambiados, los archivos de configuración de los módulos deben ser actualizados.
El ejemplo anterior es la solución preferida, pero no todos los módulos soportan este tipo de parámetro. Para estos módulos, habrá que forzar el orden correcto para su carga. Primero hay que pedirle a udev que no los cargue, colocándolos en una lista negra. Asegúrese de usar el nombre exacto del módulo a cargar. Para los dispositivos PCI, use los nombres obtenidos de la salida de la orden lspci -k, disponible en el paquete pciutils. El siguiente ejemplo usa módulos DVB.
Luego, cargue los módulos en el orden correcto. Agréguelos al /etc/conf.d/modules en el orden exacto que desee cargarlos.
El soporte para los dispositivos framebuffer (/dev/fb/*) viene con los núcleos a partir de la versión 2.6.6-rc2. Para núcleos más antiguos que la versión 2.6.4, debe explícitamente incluir el soporte para el sistema de archivos /dev/pts.
La charla sobre udev en el Linux Symposium (Ottawa, Ontario Canadá - 2003) dada por Greg Kroah-Hartman (IBM Corporation) proporcionó un sólido entendimiento acerca de la aplicación udev. Decibel's UDEV Primer es un documento, en inglés, que trata en profundidad acerca de udev y Gentoo. Writing udev rules por nuestro compañero desarrollador Gentoo Daniel Drake, es un excelente documento para aprender a personalizar su instalación udev. El contenido de este documento, a no ser que se especifique expresamente, está registrado bajo los términos de la licencia CC-BY-SA-2.5. Se aplican las Pautas de Utilización del logo y nombre de Gentoo. |
|