Corrigir o erro “Falha ao iniciar o carregamento dos módulos do kernel” na inicialização do SLES.

A mensagem de inicialização do SLES "Falha ao iniciar o carregamento dos módulos do kernel" geralmente significa que systemd-modules-load.servicefoi tentada a carga de pelo menos um módulo do kernel e uma solicitação falhou. O objetivo não é apenas ocultar a linha vermelha de inicialização. Uma boa reparação mantém o serviço íntegro, remove solicitações de módulos obsoletas, preserva qualquer driver que a máquina realmente precise e garante a compatibilidade com a próxima reinicialização.

Este guia foi escrito para o SUSE Linux Enterprise Server 15 e está alinhado com o Guia de Administração do SLES 15 SP7 atual. A documentação da SUSE sobre systemd-modules-load.serviceo carregamento de módulos nomeados em `/etc/ sysctl.conf` /etc/modules-load.d/*.conf, enquanto a maioria dos módulos de hardware modernos são normalmente carregados automaticamente quando os dispositivos são detectados. Essa distinção é importante: se uma entrada estática desatualizada apontar para um módulo que não existe mais, excluir ou corrigir essa entrada geralmente é mais seguro do que forçar a reinstalação de um driver obsoleto no sistema. Consulte a documentação da SUSE sobre Gerenciamento de módulos do kernel para o SLES 15 SP7 .

Como deve ser uma correção bem-sucedida

Antes de alterar qualquer coisa, defina o resultado desejado. Após o reparo:

• systemctl status systemd-modules-load.serviceNão deve mais reportar um resultado falho.
• O registro de erros não deverá mais exibir o mesmo erro de carregamento de módulo durante uma inicialização limpa.
• Se o módulo for realmente necessário, modprobe MODULE_NAMEa instalação deverá ser bem-sucedida e o hardware ou recurso relacionado deverá funcionar corretamente.
• Se o módulo estiver obsoleto, a solicitação desatualizada deve ser removida em vez de substituída por um módulo não relacionado.
• Se o problema estiver relacionado à inicialização do sistema, o initramfs deverá ser reconstruído e a máquina deverá reiniciar normalmente.

Se nem todas essas verificações se aplicarem à sua situação, use aquelas que correspondem ao componente com falha. Por exemplo, um servidor pode inicializar com sucesso mesmo que um módulo opcional falhe. Isso ainda vale a pena corrigir, mas é diferente de um driver de armazenamento ausente que impede a exibição do sistema de arquivos raiz.

Passo 1: Confirme a unidade com defeito e registre o erro exato do módulo.

Comece pelo próprio serviço, em vez de tentar adivinhar com base na mensagem da tela inicial:

sudo systemctl status systemd-modules-load.service --no-pager

Procure pelo nome de um módulo e por um erro como Module ... not found, No such device, Operation not permitted, ou uma mensagem indicando que um módulo não suportado foi recusado. A redação exata determina a próxima ação.

Se a saída de status estiver truncada, não edite a configuração ainda. Obtenha primeiro o log de inicialização completo.

Passo 2: Leia o diário de inicialização antes de alterar os arquivos do módulo.

Consultar somente este serviço para a inicialização atual:

sudo journalctl -b -u systemd-modules-load.service --no-pager

Você também pode inspecionar as mensagens do kernel relacionadas ao carregamento de módulos:

sudo journalctl -b -k --no-pager | grep -iE 'module|modprobe|firmware|taint'

O primeiro comando responde qual solicitação de carregamento estático falhou . O log do kernel pode adicionar contexto, como um driver que recusa o dispositivo detectado, uma dependência de firmware, problemas de assinatura ou outro erro de nível inferior.

Um resultado como esse Module foo not found in directory /lib/modules/...geralmente aponta para uma configuração desatualizada, uma incompatibilidade entre kernel e pacote, ou um driver de terceiros que não foi recompilado para o kernel ativo. No such deviceÉ diferente: o arquivo do módulo pode existir, mas o hardware ou dispositivo virtual atual pode não corresponder ao que o driver espera.

Etapa 3: Descubra quem está solicitando ao SLES que carregue esse módulo.

Pesquise os locais de carregamento estático normais e a configuração do modprobe:

grep -Rns --color=auto 'MODULE_NAME'   /etc/modules-load.d /run/modules-load.d /usr/lib/modules-load.d   /etc/modprobe.d /usr/lib/modprobe.d 2>/dev/null

Substitua MODULE_NAMEpelo nome do periódico. No SLES 15 SP7, as entradas locais em ` /etc/modules-load.d/modules-load.d` são o local padrão gerenciado pelo administrador para módulos que devem ser carregados na inicialização, enquanto as entradas empacotadas podem existir em ` /usr/lib/modules-load.d/modules-load.d`. A SUSE observa que a maioria dos módulos não precisa de uma entrada manual em `modules-load.d`.

Em seguida, verifique se o kernel ativo realmente possui o módulo:

uname -r
sudo modinfo MODULE_NAME
sudo modprobe MODULE_NAME

Se o módulo estiver obsoleto

Remova ou desative o arquivo local que faz a solicitação. Não exclua um arquivo de fornecedor /usr/libapenas para silenciar o erro, pois as atualizações de pacotes podem restaurá-lo. Se você determinar que um /etc/modules-load.d/*.confarquivo local foi criado para hardware obsoleto ou software antigo, remova essa entrada local e teste novamente.

Se o módulo deveria existir, mas o modinfo não consegue encontrá-lo.

Verifique se o kernel em execução corresponde à árvore de módulos instalada:

uname -r
ls -ld /lib/modules/$(uname -r)
rpm -q kernel-default

Uma verificação de qualidade comum é simples: /lib/modules/$(uname -r)o arquivo deve existir e conter os módulos do kernel que está sendo executado. Se um driver de terceiros foi compilado para um kernel mais antigo, reinstale ou recompile esse driver para o kernel SLES atual usando o procedimento recomendado pelo fornecedor. Evite copiar um .koarquivo de outra versão do kernel apenas para modprobeencontrar algo; diferenças na ABI ou na assinatura do kernel podem tornar isso inseguro ou ineficaz.

Se o módulo estiver na lista negra

Procure por uma lista negra ou instale uma alternativa:

grep -Rns --color=auto -E '^[[:space:]]*(blacklist|install)[[:space:]]+MODULE_NAME'   /etc/modprobe.d /usr/lib/modprobe.d 2>/dev/null

Remova uma lista negra somente após confirmar o motivo de sua inclusão. Uma lista negra pode proteger o sistema de um driver conflitante. O guia de módulos da SUSE documenta tanto listas negras persistentes quanto listas negras temporárias criadas durante o GRUB, portanto, a melhor solução pode ser remover a solicitação de carregamento estático em vez de remover a lista negra.

Se o SLES reportar um módulo não suportado

Não habilite automaticamente o carregamento de módulos não suportados. O SLES marca os módulos do kernel para status de suporte, e forçar um módulo não suportado pode afetar a capacidade de suporte. A SUSE documenta o mecanismo de exceção para cenários de teste ou hotfixes de fornecedores em seu Guia de Administração. Use-o somente quando você entender a consequência para o suporte e tiver um requisito legítimo de driver. O mesmo guia atual da SUSE está disponível em Guia de Administração do SLES 15 SP7 .

Etapa 4: Recrie o initramfs somente quando a alteração afetar a inicialização do sistema.

Se o módulo com falha for necessário dentro do initramfs, ou se você alterou um driver crítico de inicialização ou uma configuração de lista negra que precisa ser refletida lá, regenere a imagem:

sudo dracut -f

A SUSE documenta especificamente a reconstrução do initramfs após alterações de drivers que afetam a inicialização. Seu guia atual sobre o processo de inicialização explica quando os drivers precisam ser adicionados ao initramfs e como ele dracuté usado para ser regenerado: Introdução ao processo de inicialização no SLES 15 SP7 .

Não execute este procedimento dracut -fcomo um ritual para cada erro de módulo opcional. Se um módulo pós-inicialização comum estiver apenas listado em `/etc/ /etc/modules-load.dinitramfs`, corrigir esse arquivo pode ser suficiente. Reconstruir o initramfs é mais relevante quando a configuração incorreta está incorporada na imagem de inicialização ou quando o driver necessário precisa estar disponível antes que o sistema de arquivos raiz real seja totalmente montado.

Verifique o reparo antes de considerar o incidente encerrado.

Primeiro teste sem reiniciar, quando for seguro fazê-lo:

sudo systemctl restart systemd-modules-load.service
systemctl status systemd-modules-load.service --no-pager
systemctl is-failed systemd-modules-load.service

Se o módulo necessário deve ser carregado, confirme:

lsmod | grep -w MODULE_NAME

Em seguida, reinicie o computador durante uma janela de manutenção apropriada e verifique a nova inicialização:

sudo reboot

Após o login:

systemctl --failed
journalctl -b -u systemd-modules-load.service --no-pager

O sinal de sucesso mais forte não é o desaparecimento da mensagem no console uma única vez. É que, após uma nova inicialização, o mesmo erro do módulo não se repita e que o hardware ou subsistema que depende do módulo continue funcionando.

Quando mudar de abordagem

Limitações desta correção

A mensagem “Falha ao iniciar o carregamento dos módulos do kernel” é um sintoma, não um defeito específico. Este procedimento aborda falhas causadas por solicitações de módulos estáticos, módulos ausentes ou incompatíveis, listas negras e sincronização do initramfs. Ele não substitui diagnósticos de hardware, suporte a drivers de terceiros, tarefas de assinatura de Inicialização Segura ou recuperação de armazenamento quando o próprio dispositivo raiz não estiver disponível.

Para sistemas SLES de produção, preserve a capacidade de suporte: prefira o módulo fornecido para o seu kernel SLES, mantenha os drivers de terceiros alinhados com a matriz de suporte do fornecedor e use os mecanismos documentados da SUSE em vez de ignorar verificações simplesmente para corrigir uma falha de serviço. O reparo estará completo quando o estado do serviço, o registro de inicialização e o hardware dependente concordarem que o problema foi resolvido.