O módulo WireGuard non se carga despois dunha actualización do kernel? Revise isto

O seu túnel funcionaba onte, a máquina reiniciouse tras unha actualización e agora a interface non levanta. Nun sistema onde WireGuard se compila como módulo externo, a causa habitual é que o módulo do disco pertence a unha versión do kernel distinta da que se executa agora. As cabeceiras cun nome similar na mesma máquina non demostran nada sobre esa coincidencia. Só a cadea de versión o decide.

Kernel en execución ou kernel instalado

Unha actualización instala un paquete de kernel novo e deixa o vello no disco ata que a máquina se reinicia. Tras o reinicio cambia a versión en execución, e calquera módulo compilado contra a anterior queda inservible aínda que os seus ficheiros sigan aí. Esa fenda explica o informe habitual dunha máquina que estaba ben antes dun reinicio e rota despois, sen ningún cambio de configuración entre medias. Tamén explica por que reinstalar as cabeceiras ás veces parece resolver o problema e outras non.

O paquete de cabeceiras que instala pode corresponder ao paquete de kernel máis recente en lugar do kernel que realmente arrincou, e nada no nome do paquete distingue eses casos; só o fai a cadea de versión. Comprobe que se executa antes de comprobar que está instalado.

Tres comprobacións antes de reconstruír

A primeira comprobación é que kernel se executa. A segunda é se existe un módulo para esa versión e se se pode atopar. A terceira é se o kernel xa o cargou. A cuarta pregunta, se se pode crear a interface, proba os privilexios e non o módulo, así que vai despois da reconstrución e non nesta lista.

Os comandos seguintes responden ás tres primeiras sen cambiar nada. Lea cada resultado antes de continuar, porque cada resposta descarta unha reparación distinta.

uname -r
ls -l /lib/modules/$(uname -r)/build
modinfo wireguard
lsmod | grep wireguard

Se a segunda liña informa de que a ruta non existe, falta a contorna de compilación do kernel en execución e nada do que compile coincidirá con el. Se modinfo falla mentres a ruta existe, pode que o módulo non estea instalado en absoluto, o cal é normal en kernels que inclúen a implementación na árbore. Se modinfo ten éxito e lsmod non mostra nada, o módulo existe pero non está cargado, o que é un problema de carga e non de compilación. Cada resultado lévao a un sitio distinto, por iso ler importa máis que os comandos.

Compile contra a versión en execución

Un módulo externo compílase contra unha árbore de kernel preparada, e a guía do kernel para módulos externos describe usar o directorio de compilación que pertence ao kernel en execución e non o que leve o número de versión máis alto. Ese directorio de compilación é unha ligazón simbólica mantida polo paquete do kernel, así que apunta á árbore da versión que está arrincada. A indirección é xustamente o punto: elimina unha elección que doutro xeito faría mal. Nomealo explicitamente fai que o obxectivo sexa inequívoco.

Un detalle importa cando a árbore só se preparou e non se compilou por completo. O obxectivo de preparación non xera o ficheiro de versionado de símbolos que necesitan algunhas compilacións externas, así que unha árbore chea de cabeceiras non é automaticamente unha contorna de compilación completa. Se unha compilación falla por símbolos que faltan, ese ficheiro é o primeiro lugar onde mirar.

sudo make -C /lib/modules/$(uname -r)/build M=$(pwd) modules
sudo make -C /lib/modules/$(uname -r)/build M=$(pwd) modules_install
sudo depmod -a

Cando as cabeceiras empaquetadas van atrasadas

Nas distribucións e ordenadores dunha soa placa que empaquetan os seus propios kernels, as cabeceiras poden ir días ou semanas por detrás da versión. O paquete de cabeceiras pode ser correcto de nome e máis antigo de contido, o que produce unha compilación que compila e despois falla ao cargar en lugar de durante a compilación. Mesturar fontes empeórao: un kernel de distribución con cabeceiras dun repositorio de terceiros, ou un kernel de fabricante con cabeceiras xenéricas, pode compilar limpiamente e aínda así ser rexeitado polo kernel en execución porque a configuración difire. Os números de versión por si sós non o resolven.

Se a máquina segue unha canle de kernel experimental, decida a conciencia se quedar alí con artefactos de compilación coincidentes ou volver ao conxunto de paquetes compatible. Repetir a actualización e esperar que as pezas encaixen non é un plan, porque a mesma discrepancia reprodúcese cada vez.

Verifique a interface tras a reconstrución

Tras unha instalación correcta, crear a interface é a proba que importa, seguida de ler que cargou realmente o kernel e que di o rexistro se se negou. Un módulo que se carga e unha interface que non se pode crear son fallos distintos con causas distintas. Os tres comandos seguintes sepáraos.

sudo ip link add wg9 type wireguard
lsmod | grep wireguard
sudo dmesg | tail -5

Se o módulo se nega a cargar, o rexistro do kernel indica o motivo, e unha discrepancia de versión só é unha das posibilidades. Lea esa liña antes de reconstruír, porque unha segunda compilación idéntica gasta os mesmos dez minutos e produce a mesma negativa. Despois retire a interface temporal para que a seguinte proba comece desde un estado limpo.