Ubuntu en Chromebook: reparar el sonido y el Wi-Fi

Ubuntu nativo o Crostini: verifica el entorno y las limitaciones del modelo

Esta guía se refiere a un Chromebook que arranca directamente en Ubuntu, instalado como sistema principal o en arranque nativo. No se aplica a Crostini: en este entorno de Linux lanzado desde ChromeOS, los dispositivos se presentan de manera diferente y Ubuntu no controla directamente la tarjeta Wi-Fi ni los altavoces internos. Si estás en la terminal de Linux de ChromeOS, detente aquí y busca ayuda específica para Crostini.

El sonido y el Wi-Fi pueden fallar al mismo tiempo, pero a menudo tienen causas independientes. El primero puede depender de la salida seleccionada, del controlador de audio o de la pila de audio; el segundo, de la radio, del controlador o del firmware. Se diagnostican por separado, sin suponer que una sola corrección solucionará ambos problemas.

Antes de cualquier modificación, realiza una copia de seguridad de tus archivos importantes y asegúrate de poder volver a un sistema funcional. Anota la versión de Ubuntu, el núcleo y la arquitectura:

grep '^PRETTY_NAME=' /etc/os-release
uname -r
uname -m

Estos comandos muestran respectivamente la distribución, la versión del núcleo y la arquitectura. Una arquitectura x86_64 no garantiza por sí sola que el Chromebook sea compatible. aarch64 o arm64 requiere verificar una documentación específica para el dispositivo; la lista de MrChromebox mencionada más abajo se refiere a dispositivos Intel/AMD x86_64 compatibles, no a Chromebooks ARM.

Identifica el board name o el HWID exacto en una documentación confiable del modelo. El nombre comercial — incluso si se refiere a una serie conocida — no es suficiente para establecer la compatibilidad. Si la placa no está documentada para el uso previsto, o si no puedes identificarla, detén las pruebas de controladores y firmware. La guía de instalación y compatibilidad de Ubuntu en Chromebook ayuda a distinguir las precauciones a tomar antes de la instalación del diagnóstico presentado aquí, que ocurre después de un arranque nativo.

Inventariza por separado la tarjeta Wi-Fi y el controlador de audio

Comienza con las herramientas ya presentes. lspci -nnk muestra los dispositivos PCI con sus identificadores entre corchetes, así como los controladores y módulos asociados. lsusb inventariza los dispositivos USB, incluyendo un adaptador de red externo. Si inxi ya está instalado, inxi -Nxxx puede detallar la parte de red. No instales un controlador para realizar esta inventarización.

lspci -nnk
lsusb

En el resultado de lspci, «Kernel driver in use» designa el controlador efectivamente vinculado al dispositivo; «Kernel modules» indica módulos candidatos, no la prueba de que un controlador funcione. Anota por separado el identificador y el nombre de la tarjeta de red y del controlador de audio. Si un comando no existe, pasa a los que están disponibles: su ausencia no es un diagnóstico de hardware.

No concluyas que una tarjeta está ausente solo por el resultado de lspci. Algunos elementos integrados no se exponen como dispositivos PCI o USB. Correlaciona la inventarización con los registros y la documentación de la placa antes de decidir.

Wi-Fi: ¿radio bloqueada, interfaz ausente o simple desconexión?

Verifica primero el estado de la radio y de la interfaz. Estos comandos no modifican la configuración:

rfkill list
nmcli device status
ip link

rfkill list indica entre otros si un dispositivo está «Soft blocked» o «Hard blocked». Un bloqueo software puede ser levantado por el sistema; un bloqueo hardware corresponde a un comando físico o a una condición impuesta por el dispositivo. No eludas este último. Verifica el control físico o el procedimiento documentado para la placa.

nmcli device status da el estado visto por NetworkManager. Una interfaz de Wi-Fi disconnected es detectada pero no está conectada: intenta una conexión normal desde los parámetros de red, luego examina la red o el enrutador si es necesario. unavailable, unmanaged o la ausencia de interfaz requieren, en su lugar, examinar el controlador, el servicio y el núcleo. El nombre de la interfaz varía: no asumas que se llama wlan0.

ip link completa esta verificación al listar las interfaces de red. Su ausencia no prueba, por sí sola, que la tarjeta física no existe: el controlador puede no haberla registrado, o el dispositivo puede no aparecer en este bus. Cruza este resultado con lspci -nnk, lsusb y los registros.

Usa nmcli radio wifi on solo si el diagnóstico confirma que la radio está desactivada o que hay un bloqueo software presente. También puedes reactivar el Wi-Fi en los parámetros de Ubuntu. Luego verifica nuevamente rfkill list y nmcli device status. Este comando no levanta un bloqueo hardware y no crea un controlador que falte.

Leer los registros del núcleo sin modificar el sistema

Busca los mensajes asociados a los nombres de controladores realmente detectados y a los términos firmware, Wi-Fi y audio. Los dos comandos siguientes son de solo lectura y filtran su salida para mantenerse legibles en una pantalla móvil:

dmesg -T | grep -Ei 
  'firmware|iwlwifi|ath|brcm|rtw|wlan|wifi|sof|snd|audio'

journalctl -b -k --no-pager | grep -Ei 
  'firmware|iwlwifi|ath|brcm|rtw|wlan|wifi|sof|snd|audio'

Si dmesg se niega a dar acceso, un administrador puede reiniciar la lectura con sudo dmesg -T. La lectura de journalctl también puede requerir permisos en algunas instalaciones. No envíes un registro completo sin haberlo depurado: elimina especialmente las direcciones MAC, números de serie y otros identificadores personales.

Un error que nombra un archivo de firmware faltante, un fallo de inicialización o un controlador que se vincula son indicios a confrontar con el identificador de hardware, la versión del núcleo y la documentación de la placa. Ninguna línea filtrada prueba por sí sola que el hardware es compatible. Los mensajes iwlwifi se refieren a los chips Intel compatibles con este controlador, no a todas las tarjetas Wi-Fi; las menciones de sof y snd se refieren a la parte de audio y se leen por separado.

Una actualización del firmware de Ubuntu no se justifica a menos que los registros mencionen un firmware faltante, que el chip y la placa estén identificados, que haya una conexión de respaldo disponible y que el paquete oficial de Ubuntu corresponda a tu instalación. Solo en este caso, primero realiza una copia de seguridad, revisa el registro correspondiente, y luego utiliza los repositorios de Ubuntu:

sudo apt update
sudo apt install --reinstall linux-firmware

No ejecutes estos comandos como prueba general: la reinstalación de linux-firmware no es una garantía de compatibilidad, y no todos los chips dependen de este paquete. Después de la instalación, revisa los mensajes del núcleo para verificar si el error identificado ha cambiado. No reinicies hasta haber cerrado y guardado tu trabajo. Si no hay ningún paquete oficial documentado que corresponda al firmware nombrado, detente: no copies un archivo upstream y no reemplaces el controlador al azar.

Sin sonido: verifica la salida antes del controlador

Comienza por Configuración > Sonido: verifica que la salida no esté en silencio, aumenta el volumen con cuidado y selecciona el dispositivo esperado. Ubuntu puede enviar el sonido a HDMI, a un auricular o a un dispositivo Bluetooth en lugar de a los altavoces internos. Si hay una salida disponible, utiliza la prueba de altavoces en los parámetros a bajo volumen. Si el sonido sale por otra salida, el problema es primero de enrutamiento, no de un firmware a reemplazar.

Luego verifica los dispositivos de audio vistos por las herramientas disponibles:

aplay -l
wpctl status

aplay -l lista las tarjetas y dispositivos ALSA cuando la herramienta está instalada. «No soundcards found» indica detección o controlador ausente, más que un simple ajuste del volumen. wpctl status, si tu sesión utiliza PipeWire y si wpctl está disponible, muestra las salidas de audio de la sesión y la que está seleccionada. Su ausencia no prueba que el controlador de hardware esté ausente.

Si ALSA ve una tarjeta pero PipeWire no ofrece una salida utilizable, examina la sesión y el servicio de audio antes de cualquier acción. Evita los reinicios a ciegas. Si ninguna tarjeta aparece, cruza lspci -nnk con los mensajes sof o snd de los registros. Un controlador ausente en la inventarización no se repara cambiando simplemente la salida; un controlador presente con HDMI o auricular seleccionado se refiere primero al enrutamiento.

Internet de respaldo y criterios para detener

Si el Wi-Fi no funciona, un adaptador Ethernet USB reconocido o un uso compartido de conexión USB puede proporcionar acceso temporal. Úsalo para recopilar los diagnósticos y, únicamente si se ha identificado el firmware faltante, obtener las actualizaciones oficiales de Ubuntu. Esta red de respaldo permite continuar la investigación; no repara la tarjeta Wi-Fi interna.

Detén las pruebas si el board name/HWID sigue siendo desconocido, si la arquitectura o el board no tienen soportes documentados, si el núcleo no ve el dispositivo tras la verificación, o si ningún controlador ni firmware oficial corresponde al identificador de hardware. Para solicitar ayuda, proporciona el board/HWID verificado, la arquitectura, la versión de Ubuntu y del núcleo, los identificadores de red y audio, los estados rfkill y nmcli, así como solo los extractos de los registros pertinentes, depurados. También indica lo que aún funciona. Una falla simultánea de sonido y Wi-Fi no es suficiente para establecer una causa común.

Preguntas frecuentes

¿Por qué el Wi-Fi funciona en ChromeOS pero no en Ubuntu?

Los dos sistemas pueden usar controladores, un núcleo o un firmware diferentes. Esto no permite, por sí solo, concluir que un controlador de Ubuntu existe para tu chip. Identifica el ID de hardware y la placa, luego verifica los mensajes del núcleo y la documentación correspondiente.

¿Puedo instalar un controlador encontrado en GitHub?

No como solución general. Un repositorio o un script comunitario puede dirigirse a un chip, un núcleo o una placa específica y conllevar riesgos. No lo instales sin correspondencia documentada con tu hardware y sin entender los cambios; prioriza los paquetes oficiales de Ubuntu.

¿Cuándo debo detener las pruebas?

Cuando el board o el chip no están identificados, cuando el soporte de la arquitectura o del board no está documentado, o cuando ninguna solución oficial corresponde a los errores encontrados. En estos casos, evita flashear, controladores y firmwares improvisados y solicita consejo con diagnósticos depurados.

Fuentes

• Ubuntu Desktop Guide — solución de problemas de red inalámbrica
• Ubuntu Desktop Guide — falta de sonido
• Linux Wireless — iwlwifi
• MrChromebox — dispositivos soportados