☰

¿Cómo determinar qué módulo contamina el kernel?

tag-icon • tag-icon fedora linux-kernel kernel-modules kernel-panic
¿Cómo determinar qué módulo contamina el kernel?

Mi kernel sigue entrando en pánico cuando se conecta a una determinada red inalámbrica. Me gustaría enviar un informe de error pero mi kernel aparentemente está contaminado. De /var/log/messages:

Apr 17 21:28:22 Eiger kernel: [13330.442453] Pid: 4095, comm: kworker/u:1 Tainted: G           O 3.8.4-102.fc17.x86_64 #1

y

[root@Eiger ~]# cat /proc/sys/kernel/tainted 
4096

No he podido encontrar documentación sobre lo que significa la máscara de bits 4096, pero la Gbandera significa que un módulo GPL externo está cargado en el kernel. ¿Cómo puedo saber qué módulo está contaminando el kernel?

Busqué [Tt]ainten /var/log/messageso dmesgy no encontré nada correspondiente a cuando se carga un módulo. Mi kernel es el último kernel de Fedora 17: 3.8.4-102.fc17.x86_64.

ACTUALIZAR: Puede deberse al rts5139módulo. Aparece lsmodpero modinfo rts5139produce. ERROR: Module rts5139 not found. Al arrancar el kernel anterior, 3.8.3-103.fc17.x86_64, este módulo no aparece en la lista lsmody el kernel no está contaminado ( /proc/sys/kernel/taintes 0).

Intenté incluir este módulo en la lista negra.

echo 'blacklist rts5139' >> /etc/modprobe.d/blacklist.conf

pero al reiniciar todavía se muestra que el kernel está contaminado.

Respuesta1

Bueno, no creo que un paquete estándar del kernel de Fedora incluya ningún módulo que pueda desencadenar esta contaminación, por lo que la pregunta es: ¿qué otros módulos del kernel ha instalado?

Los candidatos comunes serían los controladores de gráficos (aunque creo que en su mayoría establecerán el bit "propietario") y los controladores inalámbricos.

Si puede encontrar algo en el lsmodresultado que crea que puede ser candidato, ejecútelo modinfo <module-name>y vea si el resultado incluye intree: Yalgún módulo sin que eso active la contaminación que está viendo.

ACTUALIZAR: El rts5139módulo que está viendo lsmodpero que no parece estar en su sistema probablemente esté en initrd y se esté cargando desde allí al principio del proceso de arranque antes de que se monte el sistema de archivos principal.

Eso también explica por qué la lista negra no funcionará, ya que tendría que reconstruir el initrd con la lista negra actualizada. Sin embargo , reconstruir el initrd dracuthará que el módulo desaparezca de todos modos.

Respuesta2

➜  ~  dmesg | grep -i 'taint'
[   10.029333] vboxdrv: module verification failed: signature and/or required key missing - tainting kernel
[   10.029364] Disabling lock debugging due to kernel taint

Respuesta3

Otra forma de hacerlo es examinar el taintarchivo de cada módulo en /sys/module:

#!/bin/bash

cat /proc/modules |
while read module rest
do
    if [[ $(od -A n /sys/module/$module/taint) != " 000012" ]] ; then
        echo $module
    fi
done

Si un módulo no tiene contaminación, el taintarchivo solo contendrá una nueva línea, que odse representa como " 000012". No puede verificar el tamaño del archivo ya que todos los tamaños aparecen como 4096 bytes, independientemente de su contenido real.

Respuesta4

Verifique su registro de arranque o observe su proceso de arranque en la etapa inicial (antes de que sus discos se monten RW). Este podría ser un módulo defectuoso en su initrd.

¿Tiene DKMS o algo así instalado?

información relacionada