Skip to content
Sistema

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

Avatar illustré de Julien Macé 8 min read
Chromebook ouvert avec module Wi-Fi et haut-parleur lors d’un diagnostic Ubuntu
Identifier la carte Wi-Fi et la sortie audio avant de modifier le système.
Chromebook abierto con módulo Wi-Fi y altavoz durante un diagnóstico de Ubuntu
Identificar la tarjeta Wi-Fi y la salida de audio antes de modificar el sistema.

Ubuntu nativo o Crostini: verifique el entorno y los límites 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 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 te encuentras en el terminal 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, de la pila de audio o del controlador; el segundo, de la radio, del controlador o del firmware. Se diagnostican por separado, sin suponer que una única corrección solucionará ambos.

Antes de cualquier modificación, haz 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 mostrarán 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 documentación específica del 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 documentación confiable del modelo. El nombre comercial —incluso si se refiere a una línea 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 los intentos 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 se realiza después de un arranque nativo.

Inventaría 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 inventaría los dispositivos USB, incluidos un adaptador de red externo. Si inxi ya está instalado, inxi -Nxxx puede detallar la parte de red. No instales un controlador para realizar este inventario.

lspci -nnk
lsusb

En el resultado de lspci, « Kernel driver in use » se refiere al controlador efectivamente adjunto 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 basándote solo en lspci. Algunos elementos integrados no se exponen como dispositivos PCI o USB. Cruza el inventario 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 otras cosas, si un dispositivo está « Soft blocked » o « Hard blocked ». Un bloqueo de software puede ser levantado por el sistema; un bloqueo de hardware corresponde a un comando físico o a una condición impuesta por el dispositivo. No evites este último. Verifica el control físico o el procedimiento documentado para la placa.

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

ip link complementa este control listando 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.

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

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 de firmware, Wi-Fi y audio. Los siguientes dos comandos 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 acceder, 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 menciona un archivo de firmware faltante, un fallo de inicialización o un controlador que se adjunta 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 sea 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 dirigen 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, haz primero una copia de seguridad, relee el registro correspondiente y luego usa los repositorios de Ubuntu:

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

No inicies estos comandos como una 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, relee 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 mencionado, detente: no copies un archivo upstream y no reemplaces el controlador al azar.

Sin sonido: verificar la salida antes del controlador

Comienza por Configuración > Sonido: verifica que la salida no esté en silencio, aumenta el volumen con precaución y selecciona el dispositivo esperado. Ubuntu puede enviar el sonido a través de HDMI, un auricular o un dispositivo Bluetooth en lugar de a los altavoces internos. Si hay una salida disponible, utiliza la prueba de altavoces en la configuración a bajo volumen. Si el sonido sale por otra salida, el problema es principalmente 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 » sugiere una detección o un controlador ausente, más que un simple ajuste de volumen. wpctl status, si tu sesión utiliza PipeWire y 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 tomar cualquier acción. Evita reinicios a ciegas. Si ninguna tarjeta aparece, cruza lspci -nnk con los mensajes sof o snd de los registros. Un controlador ausente en el inventario no se repara simplemente cambiando la salida; un controlador presente con HDMI o auricular seleccionado es principalmente un asunto de enrutamiento.

Internet de respaldo y criterios para detenerse

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

Detén los intentos si el board name/HWID sigue siendo desconocido, si la arquitectura o la placa no cuentan con un apoyo documentado, 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 los únicos fragmentos de registros relevantes, depurados. También especifica qué sigue funcionando. 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 utilizar 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 el board, 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 script comunitario puede estar dirigido a un chip, núcleo o placa específica y conllevar riesgos. No lo instales sin una correspondencia documentada con tu hardware y sin comprender los cambios; prioriza los paquetes oficiales de Ubuntu.

¿Cuándo debo detener los intentos?

Cuando la placa o el chip no sean identificados, cuando la compatibilidad de la arquitectura o la placa no esté documentada, o cuando ninguna solución oficial corresponda a los errores reportados. En estos casos, evita flasheo, controladores y firmwares improvisados y solicita consejo con diagnósticos depurados.

Fuentes

Share Facebook X WhatsApp LinkedIn Pinterest Reddit Email