Falha no carregamento do módulo de inicialização do SLES: Encontre o driver e corrija o problema.

Quando o SLES exibe a mensagem “Falha ao iniciar o carregamento dos módulos do kernel” durante a inicialização, primeiro inspecione systemd-modules-load.serviceos logs para identificar o módulo que falhou. Se o módulo for uma entrada opcional obsoleta, remova essa solicitação da configuração; se for necessário, corrija a incompatibilidade de driver ou kernel em vez de desativar o serviço.

Este procedimento aplica-se ao SUSE Linux Enterprise Server (SLES) 15, utilizando a documentação de administração do SLES 15 SP7 como referência. Os comandos devem ser executados a partir de um console local ou de uma sessão SSH ativa com sudoacesso.

O que significa a mensagem antes de você mudar alguma coisa?

Um módulo do kernel é um driver ou recurso do kernel que pode ser carregado separadamente. Durante a inicialização, systemd-modules-load.serviceo sistema processa solicitações para carregar módulos específicos, incluindo aqueles definidos em modules-load.darquivos. Uma solicitação malsucedida pode fazer com que esse serviço falhe, mesmo que outras partes do servidor continuem em execução.

A SUSE observa que a maioria dos drivers é carregada automaticamente quando o hardware é detectado. Uma lista de módulos manual geralmente é desnecessária, portanto, uma entrada desatualizada é uma possibilidade razoável — mas a mensagem de inicialização por si só não comprova isso. Mantenha o acesso ao console, faça um snapshot do sistema ou um backup da configuração, quando disponível, e não descarregue drivers de armazenamento, rede ou cluster apenas para fazer o aviso desaparecer. Consulte o guia de administração de módulos do kernel da SUSE para obter informações sobre o modelo compatível.

Passo 1: Leia o status do serviço e seu registro de inicialização.

Comece com o status do systemd. O systemd systemdé o gerenciador de serviços responsável por iniciar os serviços e relatar seu estado.

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

A -bflag restringe journalctla inicialização atual e -useleciona este serviço. Observe acima da linha final "Falha com resultado" mensagens como "Falha ao encontrar o módulo", uma opção inválida ou um erro de permissão ou assinatura. Anote o nome exato do módulo e o texto do erro. Não presuma que o módulo mencionado no exemplo abaixo exista em seu servidor.

Se o registro de serviço não for conclusivo, verifique as mensagens do kernel para obter detalhes adicionais:

sudo journalctl -k -b --no-pager

Se o computador não conseguir estabelecer uma conexão válida, inicie um kernel instalado mais antigo a partir do GRUB, se disponível, ou utilize a mídia de recuperação do SLES. Não edite módulos críticos de inicialização a partir de uma sessão remota não testada. A SUSE documenta os filtros de journal no capítulo sobre administração do journalctl .

Passo 2: Encontre a configuração de inicialização que a solicita.

Suponha que os nomes dos periódicos sejam example_driver. Substitua esse marcador pelo nome real do módulo e, em seguida, pesquise nas listas de módulos:

sudo grep -Rns --include='*.conf' 'example_driver' \
  /etc/modules-load.d /run/modules-load.d \
  /usr/lib/modules-load.d 2>/dev/null

Cada linha correspondente indica qual arquivo solicita esse módulo na inicialização. A configuração local de um administrador geralmente reside em `/etc/systemd/system/` /etc/modules-load.d/, enquanto um pacote pode fornecer seu arquivo em `/etc/ /usr/lib/modules-load.d/systemd/system/`. Um arquivo local com o mesmo nome base tem precedência sobre o arquivo do fornecedor, conforme descrito no guia de configuração do systemd da SUSE . Se a busca não encontrar nada, examine também cat /proc/cmdlineas solicitações de módulos na inicialização e verifique se o nome da falha foi copiado corretamente.

Abra o arquivo correspondente e verifique se a entrada ainda é necessária para o hardware ou aplicativo. Um módulo solicitado para um dispositivo antigo e removido é diferente de um driver de controlador de armazenamento ou de um watchdog de cluster.

Etapa 3: Teste o módulo e, em seguida, aplique o reparo correspondente.

Verifica qual kernel está em execução e se o driver está disponível para ele. modprobeCarrega módulos do kernel e resolve dependências; sua -nopção realiza uma simulação sem inserir nenhum módulo.

uname -r
modinfo example_driver
sudo modprobe -n -v example_driver

Novamente, substitua example_driver. O teste a seco ajuda a identificar problemas de pesquisa ou configuração, mas não comprova que um driver será inicializado com sucesso em seu hardware ou que passará nas verificações de assinatura do Secure Boot. A SUSE recomenda o uso do comando `modprobe` modprobeem vez insmoddo carregamento direto; detalhes sobre os parâmetros do teste a seco podem ser encontrados no manual do `modprobe` .

Se uma entrada opcional obsoleta apontar para um módulo ausente

Faça backup do arquivo local específico e comente apenas a linha obsoleta. Por exemplo, se /etc/modules-load.d/example.confesta for a fonte confirmada:

sudo cp -a /etc/modules-load.d/example.conf \
  /etc/modules-load.d/example.conf.bak
sudoedit /etc/modules-load.d/example.conf

Altere uma única example_driverentrada para # example_driver, salve e deixe as outras solicitações de módulo intactas. Se a origem for um arquivo de pacote em /usr/lib, não edite esse arquivo de pacote diretamente; use uma substituição local devidamente revisada ou corrija a configuração do pacote. Nunca remova uma solicitação de módulo simplesmente porque modinfoo reporta como ausente se o dispositivo correspondente for necessário.

Se um módulo necessário estiver faltando ou for incompatível

Não comente essa linha. Confirme se o pacote de drivers é compatível com a saída do comando uname -re com o pacote de serviços SLES instalado. Uma mensagem de "módulo não encontrado" pode indicar que o driver correspondente não foi instalado ou não foi recompilado após uma atualização do kernel. Uma mensagem de "formato de módulo inválido" sugere um problema de compatibilidade; as linhas de log do kernel podem ajudar a identificar a causa. Restaure ou reinstale o driver compatível seguindo as instruções do SUSE ou do fabricante do hardware. Evite copiar .koarquivos aleatórios de um kernel diferente.

Se o módulo existir, mas seu índice de dependências estiver comprovadamente desatualizado, reconstrua esse índice para o kernel atual e tente novamente a simulação:

sudo depmod -a "$(uname -r)"
sudo modprobe -n -v example_driver

Esta etapa não instala um driver ausente. Se você vir a mensagem “Chave necessária não disponível” ou uma rejeição de assinatura de módulo em um sistema com Inicialização Segura (Secure Boot), siga o fluxo de trabalho de inscrição de chave confiável e assinatura de driver da SUSE; não desative a Inicialização Segura como uma solução alternativa genérica. A SUSE explica as restrições de drivers de terceiros em seu guia de implantação da Inicialização Segura .

Passo 4: Confirme se a próxima inicialização está limpa.

Após corrigir a configuração ou restaurar o driver, tente novamente o carregador e verifique seu status. Faça isso somente após validar se todas as entradas restantes estão corretas; reiniciar tentará novamente os carregamentos configurados.

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

Se a unidade for bem-sucedida, agende uma reinicialização controlada com acesso ao console e execute novamente os comandos de status e journal. A correção é confirmada quando o serviço não apresentar mais falhas na nova inicialização e qualquer hardware ou software necessário que dependa do módulo continuar funcionando. Se o erro retornar, compare o novo log com o antigo: outro módulo listado também pode estar apresentando falhas. Mantenha o backup até que essa verificação seja aprovada; não oculte o log systemd-modules-load.serviceapenas para suprimir a mensagem de inicialização.