É arriscado dar a opção de fazer e instalar um novo kernel Linux e driver na reinicialização?

Question

É uma prática comum fornecer drivers de kernel do Linux (KOs de objetos do kernel) no código-fonte e compilá-los e instalá-los no computador de destino. Por exemplo, os drivers de exibição da Nvidia, os drivers adicionais do Oracle VirtualBox são instalados dessa maneira. Também é comum receber uma nova versão do kernel (com cabeçalhos apropriados) por meio da atualização do sistema. Isso requer que o KO seja reconstruído e reinstalado, caso contrário, o dispositivo deixará de funcionar após a atualização.

Em nosso script de inicialização da instalação do produto, queremos adicionar a etapa para criar e instalar o KO em cada inicialização. O usuário pode optar por desativar e teria que criar e instalar o KO manualmente. O driver de dispositivo se comunica com um dispositivo USB. Detalhes pertinentes: 1. A recriação real acontecerá apenas uma vez quando o novo kernel for instalado, porque o make não tentará reconstruir o arquivo que já está lá e está atualizado. 2. Demora cerca de 2 segundos para recriar o driver, e milissegundos para pular a compilação durante a inicialização normal (não após a atualização do kernel) 3. No caso improvável de falha na compilação, ela não deverá travar o sistema ou torná-lo instável, mas nosso dispositivo de hardware não funcionará. 4. Algumas distribuições podem permitir o registro de ganchos, para fazer ações em determinados eventos, como a atualização do kernel. No entanto, estamos tentando implementar algo que funcione na maioria das distribuições de maneira uniforme. Nosso instalador é script + tar ou script + rpm. Infelizmente para esta versão, não temos largura de banda para preparar pacotes nativos para todas as distribuições (por exemplo, estilo debian).

Perguntas: 1. Esta é uma solução aceitável? Se não, por quê? 2. Quais são os riscos potenciais associados a essa abordagem? 3. Qual o local correto / preferido para executar durante a inicialização? rc.local ou script sob init.d ou outro? O objetivo é fazê-lo funcionar na maioria das distribuições usando o mesmo método (se for possível).

    

Answer 1

1) sim, mas você deve adicionar um tutorial claro descrevendo a maneira como podemos executar seu script manualmente para que possamos ter certeza de que o script retornará normalmente. No caso do virtualbox in centos eles adicionam um script em /etc/init.d chamado vboxdrv

Uso: /etc/init.d/vboxdrv {start | stop | stop_vms | restart | force-reload | status | setup}

Isso está claro, podemos iniciar / parar o script e obter seu status, então o risco de obter problemas na reinicialização é mínimo, desde que possamos verificar o script em um novo kernel antes de implantá-lo. Você não pode ter mais padrão do que isso, para mim é perfeito.

2) falha sistemática do processo de compilação e nenhum módulo disponível. Isso é trágico? Acho que não. Contanto que o seu script não desligue a máquina e você forneça um log completo da falha de compilação em / var / log / mymodule, não será possível fazer melhor do que isso.

3) veja 1) No centos / RHEL / fedora) o vboxdrv é executado em /etc/init.d/vboxdrv, verifica o nome da distribuição e, em seguida, fornece alguns scripts de acordo. /etc/init.d é o primeiro lugar que eu verifico quando quero mais informações sobre um daemon. Está tudo bem comigo.

    

Answer 2

Vai depender do seu hardware.

Se você fizer isso, tenha absoluta certeza de que seu script expira em poucos segundos, caso contrário, você provavelmente terá muitos administradores perguntando por que uma máquina em uma instalação de colocação no outro lado do país não funcionou. voltar depois da atualização do kernel.

Se o seu hardware é crítico para o processo de inicialização (talvez um dongle de rede ou drive usb), então ele precisará ser feito antes (provavelmente antes do novo kernel é inicializado). Caso contrário, você deseja concluir o mais tardar possível para garantir que quaisquer sistemas de arquivos montados em rede que possam ser necessários para o compilador estejam implementados. Isso também ajudará a garantir que um MTA esteja em execução, para que o processo de criação possa enviar um e-mail root se o módulo não puder ser construído por algum motivo.

    

Answer 3

O Suporte ao Módulo Dinâmico do Kernel (DKMS), detalhado aqui , permite você pré-construa o driver antes de reiniciar. O Linux Journal tem um artigo, " Explorando o DKMS " em muitos detalhes sobre como usar e configurar o DKMS.

Se você puder reconstruir antes da reinicialização, sua confiança aumentará se a reinicialização ocorrer corretamente e rapidamente.