Linux 6.16: problemas con placas base ASUS, por qué ocurre y cómo mitigarlo sin dolores de cabeza

Linux 6.16 ha llegado con más ruido del esperado: para muchos usuarios con placas base de ASUS se ha convertido en una actualización problemática. Aunque los contratiempos con las gráficas Intel parecen ir encarrilándose, en el caso de las placas de la marca taiwanesa persisten fallos nada agradables, como máquinas que se niegan a apagar o reiniciar cuando se les pide.

Además, hay quien ha visto cómo el sistema se queda colgado durante el arranque y, en ocasiones, termina en un kernel panic. En el día a día la experiencia puede parecer normal, pero al apagar, reiniciar o iniciar aparece el drama. La buena noticia es que existe un apaño sencillo que puedes aplicar si tu placa ASUS ha empezado a dar guerra tras actualizar al último kernel estable.

Qué está pasando con Linux 6.16 y las placas base de ASUS

El origen del desaguisado apunta a dos módulos del kernel orientados a funcionalidades específicas de equipos ASUS. Tras el salto a Linux 6.16, esos módulos parecen ser los culpables de cuelgues al apagar/reiniciar y de bloqueos esporádicos en el arranque. La primera revisión de mantenimiento del kernel no ha conseguido atajar el problema en todos los casos, así que conviene aplicar una mitigación mientras llega una corrección oficial.

Quien convive con estos fallos suele describir que el sistema funciona con normalidad durante las sesiones de trabajo o juego, pero cuando toca apagar o reiniciar, la máquina se queda colgada o vuelve al escritorio sin completar la acción. En los peores casos, el arranque no progresa y puede desembocar en el temido panic del kernel.

Síntomas más comunes que puedes encontrar

• Apagado que no se completa: el sistema inicia el proceso de poweroff pero no termina y se queda clavado.
• Reinicio fallido: al pedir reboot, la sesión no progresa o se queda congelada en pantallas intermedias.
• Cuelgues al iniciar: en algunos equipos, el arranque se detiene sin avanzar y puede acabar en kernel panic.
• Uso normal sin anomalías: durante el trabajo cotidiano no se notan rarezas; los problemas aparecen sobre todo en transiciones de energía.

La causa técnica: los módulos asus_wmi y asus_nb_wmi

Los fallos se han rastreado hasta dos módulos dirigidos a hardware de la marca: asus_wmi y asus_nb_wmi. No se trata de componentes oficiales del fabricante, sino de desarrollos comunitarios que amplían la compatibilidad y exponen funciones específicas de los equipos de ASUS a través de la interfaz WMI del kernel.

La hipótesis de trabajo es clara: con Linux 6.16 algo se ha torcido en la interacción de esos módulos con determinadas placas base. La mitigación que mejor resultado está dando consiste en deshabilitar temporalmente ambos módulos para recuperar la estabilidad en operaciones de apagado, reinicio y arranque.

Mitigación rápida: poner los módulos en lista negra

El remedio pasa por impedir que el sistema cargue los módulos conflictivos. Para eso, basta añadirlos a la lista negra de modprobe. Necesitarás permisos de administración; puedes abrir y editar el archivo de configuración con tu editor favorito (Vim, Nano o incluso un editor GTK instalado de forma tradicional o en formato Snap, que puede ejecutarse como root).

Abre el fichero de modprobe correspondiente con privilegios de superusuario. Si no existe, puedes crearlo sin problema: la ruta típica es la siguiente.

sudo vim /etc/modprobe.d/blacklist.conf

Si prefieres una alternativa, Nano también sirve perfectamente: la idea es la misma, abrir ese archivo con permisos elevados y editar su contenido para impedir la carga de los módulos problemáticos.

Qué líneas hay que añadir exactamente

Dentro del archivo, incluye estas dos entradas para que el kernel no cargue los módulos al inicio. Con esto, tu placa base debería volver a un comportamiento estable en apagados, reinicios y arranques.

blacklist asus_wmi
blacklist asus_nb_wmi

Guarda los cambios en el archivo y sal del editor. Si estás en Vim, :wq hará el trabajo; en Nano, Ctrl+O y luego Ctrl+X. No necesitas nada más aparte de un reinicio para que la configuración surta efecto.

Reiniciar tras la mitigación

Una vez guardados los cambios, reinicia el sistema. Dada la naturaleza del fallo que tratamos, cabe la posibilidad de que te toque forzar el apagado si se queda colgado; el clásico botonazo puede ser inevitable en este contexto. En el siguiente arranque, el sistema ya no debería cargar los módulos y el equipo tendría que responder con normalidad al apagar o reiniciar.

En muchos casos, tras aplicar la lista negra, desaparecen los cuelgues y los apagados y reinicios vuelven a ser predecibles. Si no ves mejoras, confirma que las líneas se guardaron correctamente y que la ruta del archivo es la adecuada para tu distribución.

Advertencias importantes antes de deshabilitar los módulos

Conviene recordar que asus_wmi y asus_nb_wmi no son módulos oficiales del fabricante, sino aportaciones de la comunidad. Desactivarlos puede deshabilitar funciones específicas expuestas por esas capas de compatibilidad en ciertos equipos de la marca.

Esto es especialmente relevante en dispositivos muy integrados, como PC consolizados del estilo de la ASUS ROG Ally, y en portátiles de ASUS que dependen de esos módulos para algunas características. En esos casos, la mitigación puede acarrear efectos secundarios, desde la pérdida de controles específicos hasta la ausencia de ajustes propios del fabricante.

Si estás en un sobremesa con placa base ASUS y no usas software ni utilidades que dependan de esas funciones, lo más probable es que el sistema recupere su funcionamiento habitual sin efectos colaterales apreciables durante el uso normal.

Edición del archivo: opciones y consideraciones

Puedes editar el fichero con diferentes herramientas. Con Vim, el comando mostrado más arriba abrirá la ruta directamente. Si prefieres algo más sencillo, Nano ofrece una experiencia más amigable para quien no usa Vim. También es viable recurrir a un editor gráfico GTK instalado de modo tradicional o mediante paquete Snap, que puede ejecutarse con privilegios de root para guardar cambios en rutas del sistema.

Ten en cuenta que blacklist.conf puede existir o no dependiendo de tu distribución y de los cambios previos que hayas hecho en el sistema. Si no está presente, créalo y añade las líneas indicadas. Si ya existe, limítate a incorporar al final las entradas de lista negra para los módulos conflictivos.

Cómo comprobar que la mitigación está aplicada

Tras reiniciar, deberías notar que las operaciones de energía vuelven a ser fiables. Si te interesa verificar que los módulos no se han cargado, puedes comprobarlo con las herramientas habituales del sistema, aunque lo importante es que la máquina deje de colgarse al apagar, reiniciar o arrancar.

Si tu equipo sigue comportándose de forma extraña, revisa que las líneas de la lista negra estén exactamente como se muestran más arriba y que no haya errores tipográficos. Asegúrate también de que el archivo está en la carpeta /etc/modprobe.d y de que se guardaron los cambios correctamente.

Cómo revertir la mitigación si notas efectos secundarios

Si observas que tras deshabilitar los módulos pierdes alguna función relevante en tu equipo, puedes revertir la mitigación. Abre de nuevo el archivo de configuración y elimina las dos líneas añadidas (o coméntalas). Guarda, reinicia y el sistema volverá a cargar asus_wmi y asus_nb_wmi como antes.

En dispositivos donde esas capas proporcionan funciones críticas, como algunos portátiles ASUS o equipos muy integrados, puede que prefieras esperar al arreglo oficial antes de mantener la lista negra de forma permanente.

Estado del arreglo oficial y qué esperar

Los desarrolladores del kernel son conscientes del problema que afecta a las placas base de ASUS en Linux 6.16. Aunque la primera versión de mantenimiento tras el lanzamiento no lo ha arreglado para todos, se espera que una actualización futura aborde la raíz del fallo sin necesidad de recurrir a mitigaciones.

Mientras tanto, esta solución de compromiso es una vía simple y efectiva para estabilizar los equipos afectados, especialmente en equipos de sobremesa donde esas capas de ASUS no son determinantes para el uso corriente. Si en tu caso todo queda estable y no echas en falta ninguna función, la mitigación podría incluso quedarse como medida duradera.

Consejos prácticos para aplicar el cambio con seguridad

Antes de tocar nada, asegúrate de tener a mano un medio de arranque alternativo por si necesitas recuperar el sistema. Es improbable que lo precises para esta mitigación, pero nunca está de más ser prudente cuando editas configuraciones del kernel.

A la hora de editar, verifica que estás usando el comando con sudo o que has iniciado sesión como root, porque sin permisos de administración no podrás guardar cambios en la carpeta del sistema. Una sola letra fuera de sitio hará que la lista negra no tenga efecto.

Tras el reinicio, prueba específicamente lo que te fallaba: solicita un apagado completo y un reinicio para comprobar que ya no hay cuelgues. Si también sufrías bloqueos de arranque, realiza un par de ciclos de encendido para confirmar que todo vuelve a la normalidad.

Cuándo aplicar la mitigación y cuándo esperar

Si dependes de tu equipo a diario y sufres cuelgues al apagar o reiniciar desde que actualizaste a Linux 6.16, aplicar esta solución es razonable. Es rápida, reversible y suele funcionar en sobremesas ASUS que no emplean funciones especiales de la marca.

Si utilizas un dispositivo con mucha integración de software y hardware de ASUS (como ciertas consolas portátiles o portátiles de la marca) y sospechas que podrías perder funciones clave, puede que prefieras esperar a que llegue la revisión oficial del kernel, probando la mitigación solo si los cuelgues te impiden trabajar con normalidad.

En todos los casos, conviene estar atento a las actualizaciones del kernel: cuando se publique la corrección, podrás quitar la lista negra y recuperar los módulos sin miedo a que reaparezcan los problemas.

Si hace poco te llegó el kernel 6.16 a tu distribución (por ejemplo, a escritorios que lo han adoptado recientemente) y la primera revisión no te ha solucionado el asunto, esta mitigación es hoy por hoy la forma más simple de devolver la estabilidad sin esperar a un parche posterior.

A la vista de lo descrito, el cuadro es claro: el conflicto reside en dos módulos concretos, y su inhabilitación devuelve a la máquina a un estado manejable. Cuando el equipo del kernel publique la solución, podrás retirar la mitigación y volver a cargar asus_wmi y asus_nb_wmi con total tranquilidad.