Tutorial depmod en Linux: uso práctico, opciones y ejemplos

Si trabajas con Linux y tocas algo del kernel tarde o temprano te vas a cruzar con depmod y el fichero modules.dep. Puede que lo hayas visto al actualizar el sistema, al instalar drivers externos o, como le pasa a mucha gente, cuando un programa como VirtualBox deja de cargar sus módulos y aparece el clásico “módulo no encontrado”.

En este artículo vamos a profundizar en qué hace exactamente el comando depmod en Linux, cómo funciona por dentro, qué papel juegan los ficheros de configuración depmod.d y cómo puedes usarlo en tu día a día para evitar problemas con los módulos del kernel. Todo explicado en castellano de España, con ejemplos claros y sin dar nada por supuesto más allá de que sabes abrir una terminal.

Qué es depmod y para qué sirve en Linux

El comando depmod es una herramienta de espacio de usuario que se encarga de analizar todos los módulos de un determinado kernel e identificar qué símbolos exportan y cuáles necesitan. A partir de ese análisis genera un fichero de dependencias, normalmente llamado modules.dep, que el sistema utiliza para saber qué módulos deben cargarse antes que otros.

En Linux, los módulos del kernel pueden ofrecer servicios a otros módulos a través de símbolos, que en el código se marcan con macros como EXPORT_SYMBOL. Cuando un segundo módulo utiliza uno de esos símbolos, pasa a depender del primero. En instalaciones con muchos módulos cargables, esta red de dependencias puede volverse bastante compleja si no se gestiona bien.

La misión de depmod es sencilla de describir pero muy importante: recorre el árbol de módulos en /lib/modules/<versión>, mira qué símbolos exporta cada módulo y qué símbolos requiere, y construye a partir de ahí la lista de dependencias. De esta forma, cuando otra herramienta como modprobe quiera cargar un módulo determinado, sabrá de antemano qué otros módulos deben cargarse primero.

Además de modules.dep, depmod también genera varios ficheros de “mapa” en el mismo directorio, que son utilizados por la infraestructura de hotplug y por las herramientas de kmod para gestionar la carga dinámica de módulos (por ejemplo, cuando enchufas un dispositivo USB y el sistema decide qué driver cargar).

Sintaxis básica del comando depmod

La forma más simple de usar la herramienta es llamarla sin opciones, lo que hace que genere el fichero modules.dep para el kernel en ejecución. La sintaxis general, según la página de manual, es esta:

depmod

También se puede invocar especificando módulos concretos como argumentos, en cuyo caso depmod solo examina esos módulos. Esta forma de uso es menos habitual, porque normalmente interesa tener las dependencias de todo el árbol de módulos actualizado, no solo de uno individual.

En términos formales, la página de manual presenta algo parecido a:

depmod
depmod

En estas variantes, la versión se refiere a la versión de kernel (por ejemplo 5.4.0-81-generic) cuyo directorio de módulos debe analizarse. Si no se indica nada, depmod utiliza la versión retornada por uname -r, es decir, el kernel que se está ejecutando en ese momento.

Parámetros y opciones más importantes de depmod

El comando cuenta con varias opciones que permiten ajustar su comportamiento. Muchas de ellas son esenciales cuando trabajas con entornos de compilación, kernels custom o staging areas. A continuación se resumen las más utilizadas:

Opción / Parámetro	Descripción
kernel_version	Parámetro opcional que indica la versión del kernel para la que se generarán las dependencias. Si se omite, se usa el kernel en ejecución.
-a, --all	Hace que depmod genere información de dependencias para todas las versiones de kernel instaladas. Si no se pasan nombres de fichero en la línea de comandos, este modo está activado por defecto.
-A, --quick	Modo rápido: depmod comprueba si hay módulos más nuevos que modules.dep y, si no los hay, sale sin regenerar nada. Ahorra tiempo en sistemas con muchos módulos.
-b <basedir>, --basedir <basedir>	Permite indicar un directorio base alternativo donde se encuentran los módulos. Es muy útil si estás trabajando en un directorio de staging, distinto de /lib/modules/<versión>. El basedir se elimina de las rutas que se escriben en modules.dep, dejando el fichero listo para moverse a la ubicación definitiva.
-C <archivo o directorio>, --config	Con esta opción se puede sustituir el fichero de configuración por defecto (normalmente /etc/depmod.conf o el directorio /etc/depmod.d/ si no existe el primero).
-e, --errsyms	Cuando se combina con -F, hace que depmod informe de los símbolos que necesita un módulo y que no son proporcionados ni por otros módulos ni por el propio kernel.
-F <System.map>, --filesyms	Permite indicar el fichero System.map generado al compilar el kernel, de manera que depmod sepa qué símbolos están ya resueltos dentro del propio núcleo y pueda reportar correctamente los que faltan.
-h, --help	Muestra un mensaje de ayuda breve sobre el uso del comando y termina la ejecución.
-n, --dry-run	Realiza todos los cálculos pero escribe la salida en la consola (stdout) en lugar de generar los ficheros sobre el directorio de módulos. Muy válido para comprobar qué haría depmod sin tocar nada.
-v, --verbose	Modo detallado: depmod muestra por pantalla todos los símbolos de los que depende cada módulo y el nombre del módulo que los proporciona.
-V, --version	Muestra la versión del programa depmod y sale. En kernels muy antiguos puede haber consideraciones adicionales, según advierte la propia documentación.

Además de las opciones, conviene recordar que si se le pasan nombres de archivo de módulos como argumentos, depmod se limita a examinarlos a ellos en lugar de procesar todo el contenido del directorio de módulos correspondiente a la versión del kernel seleccionada.

Caso práctico: cómo depmod puede arreglar problemas con módulos (ejemplo con VirtualBox)

Un ejemplo muy representativo de la utilidad de depmod es el caso de VirtualBox que deja de funcionar porque “faltan” módulos del kernel. Imagina una situación real: tras una actualización o recompilación del kernel, al intentar arrancar una máquina virtual, VirtualBox avisa de que no puede cargar el módulo vboxdrv u otros módulos asociados.

En un caso así es frecuente encontrarse con mensajes de error relacionados con System.map y con la ausencia de ciertos módulos en las rutas esperadas. Puede ocurrir, por ejemplo, que el fichero System.map no se encuentre donde depmod o las herramientas del sistema esperan verlo (por ejemplo, en /usr/src/linux), aunque sí exista en /boot.

Una solución ampliamente comentada en foros técnicos (como puede ser un foro de Arch o un entorno Gentoo) suele consistir en ejecutar un simple sudo depmod -a para forzar la regeneración del fichero modules.dep de la versión de kernel que estás usando. Después de ese paso, se prueba a cargar manualmente el módulo con modprobe vboxdrv y, si todo está bien, el error desaparece.

Lo que realmente hace ese comando es volver a recorrer todos los módulos disponibles para ese kernel, recalcular el mapa de símbolos exportados y requeridos y actualizar los ficheros de dependencias y mapas utilizados por otras herramientas, incluido modprobe. Si había inconsistencias entre los módulos presentes y lo que aparecía en modules.dep, se corrigen.

En términos prácticos, esto significa que si has instalado, recompilado o movido módulos (como los de VirtualBox) sin regenerar las dependencias, depmod “pone orden” para que el sistema vuelva a saber quién depende de quién y qué se debe cargar antes de qué.

Cómo depmod genera modules.dep y otros ficheros de mapa

Profundizando un poco más, depmod funciona analizando todos los módulos encontrados bajo /lib/modules/<versión> o el directorio que se haya configurado. Por cada módulo, inspecciona qué símbolos exporta (es decir, qué funciones o variables ofrece a otros módulos) y qué símbolos necesita para funcionar.

Con esta información, depmod construye una lista de dependencias en el fichero modules.dep, ubicada en el mismo directorio de módulos. Cada línea del fichero indica un módulo y los módulos de los que depende, lo que sirve como base para herramientas como modprobe a la hora de cargar módulos en el orden correcto.

La herramienta también se encarga de generar otros ficheros de mapa para la infraestructura de hotplug y para el sistema de gestión de módulos en general. Aunque como usuario normal no suelas editarlos directamente, son fundamentales para que la carga automática de módulos funcione cuando se detecta nuevo hardware.

Si en la invocación de depmod se especifica una versión de kernel concreta, se utiliza el directorio correspondiente a esa versión en lugar de la versión actual informada por uname -r. Esto resulta útil cuando preparas módulos para un kernel que aún no estás ejecutando, por ejemplo en entornos de compilación cruzada o chroot.

En escenarios más avanzados, también se usa la opción -F System.map para suministrar el mapa de símbolos del kernel que se generó en la compilación. Gracias a esto, depmod puede distinguir entre símbolos resueltos por el propio núcleo y símbolos que deberían suministrar los módulos externos, y así emitir advertencias más precisas con la opción -e.

Directorio de configuración depmod.d y ajuste de prioridades

Además del comando en sí, depmod cuenta con un sistema de configuración flexible basado en el directorio depmod.d y posibles ficheros depmod.conf. Esta configuración permite cambiar el orden en que se procesan los módulos y definir qué versión de un módulo debe considerarse prioritaria cuando hay más de una disponible.

Según la documentación, depmod lee las configuraciones de estas rutas:

• /usr/lib/depmod.d/*.conf
• /etc/depmod.d/*.conf
• /run/depmod.d/*.conf

Los ficheros bajo estas rutas usan un formato de texto sencillo, con una instrucción por línea. Se permiten líneas en blanco, y las que comienzan con # se tratan como comentarios. Si una línea termina en \, la instrucción continúa en la siguiente línea, algo útil para mantener las configuraciones largas más ordenadas.

Dentro de esos ficheros se pueden usar principalmente dos tipos de comandos: search y override. Ambos sirven para controlar qué módulos se procesan antes o después, y qué versión debería prevalecer en caso de conflicto.

Comando search en depmod.d: orden de procesamiento de módulos

El comando search dentro de depmod.d sirve para definir en qué orden se procesan los subdirectorios de /lib/modules (u otra ubicación configurada de módulos) cuando depmod analiza el sistema.

La sintaxis general es algo como:

search subdirectorio1 subdirectorio2 ...

Los directorios se listan de mayor a menor prioridad: el primero tiene prioridad máxima y el último prioridad mínima. Además, existe una palabra clave especial, built-in, que hace referencia a los directorios de módulos estándar instalados por el kernel.

Por defecto, depmod otorga más importancia a un subdirectorio llamado updates respecto a los módulos integrados, utilizando internamente la cadena de búsqueda "updates built-in". Esto permite que, si instalas versiones actualizadas de módulos en updates, se usen preferentemente sobre las que venían con el kernel de serie.

Con configuraciones más complejas basadas en search se pueden montar esquemas habituales en muchas distribuciones, donde módulos personalizados o de terceros se colocan en rutas específicas para que tengan prioridad sobre los que suministra el kernel sin tocar estos últimos.

Comando override en depmod.d: selección de versión específica de un módulo

El otro comando importante en depmod.d es override, pensado para elegir qué versión de un módulo usar cuando existen varias con el mismo nombre. Esto sucede con frecuencia cuando tienes el módulo que trae el kernel y, además, una versión propia o experimental.

La sintaxis general es:

override modulename kernelversion modulesubdirectory

En esta instrucción, el parámetro modulename identifica el módulo al que queremos dar prioridad, kernelversion puede ser una versión concreta o el comodín * (para aplicarlo a todos los kernels), y modulesubdirectory es el subdirectorio dentro de /lib/modules (u otra ruta de módulos) donde se encuentra la versión “ganadora”.

Un ejemplo típico es algo como:

override kmod * extra

Con esta línea se consigue que, para cualquier versión de kernel, si existe un módulo llamado kmod bajo el subdirectorio extra, esa versión tome prioridad frente a otra versión con el mismo nombre que venga con el kernel o se encuentre en otros directorios estándar.

Este tipo de reglas son especialmente útiles cuando se quiere probar drivers personalizados o versiones de prueba sin eliminar la versión original del sistema, manteniendo la posibilidad de volver atrás simplemente ajustando o eliminando la configuración de override.

Funcionamiento interno y relación con otras herramientas (modprobe, kmod, hotplug)

depmod no trabaja aislado, sino que forma parte del ecosistema de herramientas de gestión de módulos en Linux (kmod). Su trabajo se ve reflejado de forma directa en cómo se comportan comandos como modprobe o en cómo el sistema carga módulos automáticamente al detectar nuevo hardware.

Cuando ejecutas modprobe nombre_modulo, esta herramienta consulta el contenido de modules.dep y otros ficheros generados por depmod para determinar qué módulos hay que cargar previamente para satisfacer las dependencias. Si esos ficheros están desactualizados o corruptos, modprobe puede fallar con errores de símbolos no resueltos o módulos no encontrados.

La infraestructura de hotplug también se apoya en estas dependencias. Cuando enchufas un dispositivo o el kernel detecta un nuevo componente, el sistema de udev y las herramientas asociadas preguntan qué módulo cargar, y la respuesta depende en gran parte de las tablas construidas a partir del trabajo de depmod.

Además, todo esto se integra en el proyecto kmod, que proporciona las herramientas de espacio de usuario para gestionar módulos. El manual de depmod.d indica que esta parte de la documentación forma parte del proyecto kmod y que, si se detectan errores o mejoras, se pueden comunicar a listas de correo específicas dedicadas a los módulos de Linux.

Gracias a esta integración, depmod se ejecuta de forma automática en muchos casos, por ejemplo tras instalar un nuevo kernel o al instalar paquetes que añaden módulos. No obstante, como has visto, sigue siendo muy útil ejecutarlo manualmente cuando hay problemas o cambios fuera del ciclo normal de paquetes.

Ejemplos prácticos de uso de depmod

Para terminar de aterrizar la teoría, conviene ver algunos ejemplos de cómo se utiliza depmod en situaciones reales, desde las más sencillas hasta las que implican entornos un poco más avanzados.

Generar dependencias para el kernel en ejecución

El caso más habitual es simplemente forzar la actualización de las dependencias del kernel actual con:

sudo depmod

Al no pasar ninguna versión, depmod toma la que devuelve uname -r y actualiza modules.dep y los mapas para ese kernel. También se puede usar explícitamente:

sudo depmod -a

La opción -a indica “procesar todos los módulos”, y es el comportamiento que adopta depmod cuando no se le dan nombres de fichero concretos. En muchos tutoriales se suele ver precisamente este comando como solución a problemas con módulos que no se cargan.

Generar dependencias para una versión de kernel específica

Si tienes instalado más de un kernel, o estás preparando módulos para uno que todavía no está arrancado, puedes indicarle a depmod qué versión usar:

sudo depmod 5.4.0-81-generic

Con esto, el comando trabajará sobre /lib/modules/5.4.0-81-generic y generará allí el fichero modules.dep y demás mapas, sin tocar los del kernel que esté corriendo en ese momento.

Regenerar dependencias para todos los kernels instalados

En sistemas donde conviven varios kernels, como servidores que mantienen versiones antiguas por seguridad, puede resultar conveniente forzar la regeneración de dependencias para todas las versiones con un solo comando:

sudo depmod -a

En este contexto, depmod recorre las distintas versiones bajo /lib/modules y actualiza modules.dep para cada una de ellas, asegurándose de que todas queden coherentes tras actualizar módulos o aplicar cambios.

Uso con directorios de staging y opción –basedir

Cuando trabajas con kernels personalizados o entornos de construcción, es habitual tener los módulos en un directorio temporal diferente a /lib/modules. En esa situación, se puede utilizar la opción -b o --basedir:

depmod -b /ruta/al/staging 5.4.0-81-generic

Con esto, depmod trata /ruta/al/staging/lib/modules/5.4.0-81-generic como su directorio de trabajo, pero al generar modules.dep elimina la parte del basedir de las rutas. Así, el fichero queda listo para ser movido más tarde a la ruta estándar sin tener que volver a generarlo.

Comprobación de símbolos no resueltos con System.map

En entornos de desarrollo o depuración profunda de módulos, puede venir muy bien usar depmod para detectar símbolos no resueltos combinando las opciones -F y -e:

depmod -F /boot/System.map-5.4.0-81-generic -e 5.4.0-81-generic

En este caso, se proporciona el fichero System.map generado al compilar el kernel, lo que permite a depmod identificar qué símbolos deberían estar ya definidos en el núcleo. Con la opción -e, el comando informa de aquellos símbolos que necesita algún módulo y que no están presentes ni en el kernel ni en ningún otro módulo, lo que suele indicar un problema de compilación, de versión o de configuración.

Cuando se detectan estos símbolos “huérfanos”, es una pista muy clara de que algo no cuadra entre el kernel, los módulos instalados y las cabeceras usadas para compilar. En ese tipo de situaciones, revisar System.map y la salida detallada de depmod puede ahorrar mucho tiempo.

En conjunto, depmod se convierte en una pieza básica de la gestión de módulos en Linux: sin él, el sistema perdería la visión global de las dependencias entre módulos y herramientas como modprobe o la propia infraestructura de hotplug no podrían trabajar correctamente. Entender qué hace, cómo se configura mediante depmod.d y en qué casos conviene lanzarlo manualmente te da bastante margen para diagnosticar y solucionar problemas con drivers y módulos del kernel de forma más rápida y segura.