☰

Como determinar qual módulo contamina o kernel?

tag-icon • tag-icon fedora linux-kernel kernel-modules kernel-panic
Como determinar qual módulo contamina o kernel?

Meu kernel continua em pânico quando conectado a uma determinada rede sem fio. Gostaria de enviar um relatório de bug, mas meu kernel aparentemente está corrompido. 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

e

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

Não consegui encontrar documentação sobre o que significa a máscara de bits 4096, mas o Gsinalizador significa que um módulo GPL externo é carregado no kernel. Como descubro qual módulo está contaminando o kernel?

Procurei [Tt]aintem /var/log/messagesou dmesge não encontrei nada correspondente a quando um módulo é carregado. Meu kernel é o kernel mais recente do Fedora 17: 3.8.4-102.fc17.x86_64.

ATUALIZAR: Pode ser devido ao rts5139módulo. Ele aparece, lsmodmas modinfo rts5139produz ERROR: Module rts5139 not found. Ao inicializar o kernel anterior, 3.8.3-103.fc17.x86_64, este módulo não é listado por lsmode o kernel não está contaminado ( /proc/sys/kernel/tainté 0).

Eu tentei colocar este módulo na lista negra

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

mas a reinicialização ainda mostra o kernel contaminado.

Responder1

Bem, eu não acredito que um pacote de kernel padrão do Fedora inclua quaisquer módulos que possam desencadear essa contaminação, então a questão é: quais outros módulos do kernel você instalou?

Candidatos comuns seriam drivers gráficos (embora eu ache que eles definirão principalmente o bit "proprietário") e drivers sem fio.

Se você encontrar algo na lsmodsaída que você acha que pode ser candidato, execute modinfo <module-name>e veja se a saída inclui intree: Yalgum módulo sem que isso acione a contaminação que você está vendo.

ATUALIZAR: O rts5139módulo que você está vendo, lsmodmas que não parece estar no seu sistema, provavelmente está no initrd e está sendo carregado a partir daí no início do processo de inicialização, antes que o sistema de arquivos principal seja montado.

Isso também explica por que a lista negra não funcionará, pois você teria que reconstruir o initrd com a lista negra atualizada. Reconstruir o initrd dracutfará com que o módulo desapareça de qualquer maneira.

Responder2

➜  ~  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

Responder3

Outra maneira de fazer isso é examinar o taintarquivo de cada módulo em /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

Se um módulo não tiver contaminação, o taintarquivo conterá apenas uma nova linha, que odrepresenta como " 000012". Você não pode verificar o tamanho do arquivo, pois todos os tamanhos estão listados como 4.096 bytes, independentemente do conteúdo real.

Responder4

Verifique seu log de inicialização ou observe seu processo de inicialização no estágio inicial (antes de seus discos serem montados em RW). Este pode ser um módulo ruim no seu initrd.

Você tem DKMS ou algo parecido em vigor?

informação relacionada