Ubuntu native ou Crostini : vérifiez l’environnement et les limites du modèle
Ce guide concerne un Chromebook qui démarre directement sur Ubuntu, installé comme système principal ou en démarrage natif. Il ne s’applique pas à Crostini : dans cet environnement Linux lancé depuis ChromeOS, les périphériques sont présentés différemment et Ubuntu ne pilote pas directement la carte Wi-Fi ni les haut-parleurs internes. Si vous êtes dans le terminal Linux de ChromeOS, arrêtez-vous ici et cherchez une aide propre à Crostini.
Le son et le Wi-Fi peuvent tomber en panne en même temps, mais ils ont souvent des causes indépendantes. Le premier peut dépendre de la sortie sélectionnée, de la pile audio ou du contrôleur ; le second, de la radio, du pilote ou du firmware. On les diagnostique séparément, sans supposer qu’une seule correction réglera les deux.
Avant toute modification, sauvegardez vos fichiers importants et assurez-vous de pouvoir revenir à un système fonctionnel. Relevez la version d’Ubuntu, le noyau et l’architecture :
grep '^PRETTY_NAME=' /etc/os-release
uname -r
uname -mCes commandes affichent respectivement la distribution, la version du noyau et l’architecture. Une architecture x86_64 ne garantit pas à elle seule que le Chromebook est pris en charge. aarch64 ou arm64 impose de vérifier une documentation spécifique à l’appareil ; la liste MrChromebox citée plus bas porte sur les appareils Intel/AMD x86_64 pris en charge, pas sur les Chromebook ARM.
Identifiez le board name ou le HWID exact dans une documentation fiable du modèle. Le nom commercial — même s’il désigne une gamme connue — ne suffit pas à établir la compatibilité. Si le board n’est pas documenté pour l’usage envisagé, ou si vous ne pouvez pas l’identifier, arrêtez les essais de pilotes et de firmware. Le guide d’installation et de compatibilité d’Ubuntu sur Chromebook aide à distinguer les précautions prises avant l’installation du diagnostic présenté ici, qui intervient après un démarrage natif.
Inventoriez séparément la carte Wi-Fi et le contrôleur audio
Commencez par les outils déjà présents. lspci -nnk affiche les périphériques PCI avec leurs identifiants entre crochets, ainsi que les pilotes et modules associés. lsusb inventorie les périphériques USB, notamment un adaptateur réseau externe. Si inxi est déjà installé, inxi -Nxxx peut détailler la partie réseau. N’installez pas un pilote pour réaliser cet inventaire.
lspci -nnk
lsusbDans le résultat de lspci, « Kernel driver in use » désigne le pilote effectivement attaché au périphérique ; « Kernel modules » indique des modules candidats, pas la preuve qu’un pilote fonctionne. Notez séparément l’identifiant et le nom de la carte réseau et du contrôleur audio. Si une commande n’existe pas, passez à celles qui sont disponibles : son absence n’est pas un diagnostic matériel.
Ne concluez pas qu’une carte est absente sur la seule base de lspci. Certains éléments embarqués ne sont pas exposés comme périphériques PCI ou USB. Recoupez l’inventaire avec les journaux et la documentation du board avant de décider.
Wi-Fi : radio bloquée, interface absente ou simple déconnexion ?
Vérifiez d’abord l’état de la radio et de l’interface. Ces commandes ne modifient pas la configuration :
rfkill list
nmcli device status
ip linkrfkill list indique notamment si un périphérique est « Soft blocked » ou « Hard blocked ». Un blocage logiciel peut être levé par le système ; un blocage matériel correspond à une commande physique ou à une condition imposée par l’appareil. Ne contournez pas ce dernier. Vérifiez le contrôle matériel ou la procédure documentée pour le board.
nmcli device status donne l’état vu par NetworkManager. Une interface Wi-Fi disconnected est détectée mais n’est pas connectée : tentez une connexion normale depuis les paramètres réseau, puis examinez le réseau ou le routeur si nécessaire. unavailable, unmanaged ou l’absence d’interface demande plutôt d’examiner le pilote, le service et le noyau. Le nom de l’interface varie : ne partez pas du principe qu’elle s’appelle wlan0.
ip link complète ce contrôle en listant les interfaces réseau. Son absence ne prouve pas, à elle seule, que la carte physique n’existe pas : le pilote peut ne pas l’avoir enregistrée, ou le périphérique peut ne pas apparaître sur ce bus. Croisez ce résultat avec lspci -nnk, lsusb et les journaux.
Utilisez nmcli radio wifi on uniquement si le diagnostic confirme que la radio est désactivée ou qu’un blocage logiciel est présent. Vous pouvez aussi réactiver le Wi-Fi dans les paramètres Ubuntu. Vérifiez ensuite à nouveau rfkill list et nmcli device status. Cette commande ne lève pas un blocage matériel et ne crée pas un pilote manquant.
Lire les journaux du noyau sans modifier le système
Recherchez les messages associés aux noms de pilotes réellement repérés et aux termes de firmware, Wi-Fi et audio. Les deux commandes suivantes sont en lecture seule et filtrent leur sortie pour rester lisibles sur un écran mobile :
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 refuse l’accès, un administrateur peut relancer la lecture avec sudo dmesg -T. La lecture de journalctl peut aussi nécessiter des droits sur certaines installations. N’envoyez pas un journal complet sans l’avoir expurgé : retirez notamment les adresses MAC, numéros de série et autres identifiants personnels.
Une erreur qui nomme un fichier de firmware manquant, un échec d’initialisation ou un pilote qui s’attache sont des indices à confronter à l’identifiant matériel, à la version du noyau et à la documentation du board. Aucune ligne filtrée ne prouve à elle seule que le matériel est pris en charge. Les messages iwlwifi concernent les puces Intel compatibles avec ce pilote, pas toutes les cartes Wi-Fi ; les mentions sof et snd orientent vers la partie audio et se lisent séparément.
Une mise à jour du firmware Ubuntu ne se justifie que si les journaux nomment un firmware manquant, que la puce et le board sont identifiés, qu’une connexion de secours est disponible et que le paquet officiel Ubuntu correspond à votre installation. Dans ce cas seulement, sauvegardez d’abord, relisez le journal concerné, puis utilisez les dépôts Ubuntu :
sudo apt update
sudo apt install --reinstall linux-firmwareNe lancez pas ces commandes comme essai général : la réinstallation de linux-firmware n’est pas une garantie de prise en charge, et toutes les puces ne reposent pas sur ce paquet. Après l’installation, relisez les messages du noyau pour vérifier si l’erreur identifiée a changé. Ne redémarrez qu’après avoir fermé et sauvegardé votre travail. Si aucun paquet officiel documenté ne correspond au firmware nommé, arrêtez-vous : ne copiez pas un fichier upstream et ne remplacez pas le pilote au hasard.
Sans son : vérifier la sortie avant le contrôleur
Commencez par Paramètres > Son : vérifiez que la sortie n’est pas muette, augmentez le volume avec prudence et sélectionnez le périphérique attendu. Ubuntu peut envoyer le son vers HDMI, un casque ou un appareil Bluetooth plutôt que vers les haut-parleurs internes. Si une sortie est disponible, utilisez le test de haut-parleurs des paramètres à faible volume. Si le son sort par une autre sortie, le problème relève d’abord du routage, pas d’un firmware à remplacer.
Vérifiez ensuite les périphériques audio vus par les outils disponibles :
aplay -l
wpctl statusaplay -l liste les cartes et périphériques ALSA lorsque l’outil est installé. « No soundcards found » oriente vers une détection ou un pilote absent, plutôt que vers le simple réglage du volume. wpctl status, si votre session utilise PipeWire et si wpctl est disponible, montre les sorties audio de la session et celle qui est sélectionnée. Son absence ne prouve pas que le contrôleur matériel est absent.
Si ALSA voit une carte mais que PipeWire ne propose pas de sortie utilisable, examinez la session et le service audio avant toute action. Évitez les redémarrages à l’aveugle. Si aucune carte n’apparaît, recoupez lspci -nnk avec les messages sof ou snd des journaux. Un contrôleur absent de l’inventaire ne se répare pas en changeant simplement la sortie ; un contrôleur présent avec HDMI ou casque sélectionné relève d’abord du routage.
Internet de secours et critères d’arrêt
Si le Wi-Fi ne fonctionne pas, un adaptateur Ethernet USB reconnu ou un partage de connexion USB peut fournir un accès temporaire. Servez-vous-en pour recueillir les diagnostics et, uniquement si le firmware manquant a été identifié, obtenir les mises à jour officielles Ubuntu. Ce réseau de secours permet de poursuivre l’enquête ; il ne répare pas la carte Wi-Fi interne.
Arrêtez les essais si le board name/HWID reste inconnu, si l’architecture ou le board ne dispose pas d’un support documenté, si le noyau ne voit pas le périphérique après vérification, ou si aucun pilote ni firmware officiel ne correspond à l’identifiant matériel. Pour demander de l’aide, fournissez le board/HWID vérifié, l’architecture, la version d’Ubuntu et du noyau, les identifiants réseau et audio, les états rfkill et nmcli, ainsi que les seuls extraits de journaux pertinents, expurgés. Précisez aussi ce qui fonctionne encore. Une panne simultanée de son et de Wi-Fi ne suffit pas à établir une cause commune.
Questions fréquentes
Pourquoi le Wi-Fi marche sous ChromeOS mais pas sous Ubuntu ?
Les deux systèmes peuvent utiliser des pilotes, un noyau ou un firmware différents. Cela ne permet pas, à lui seul, de conclure qu’un pilote Ubuntu existe pour votre puce. Identifiez l’ID matériel et le board, puis vérifiez les messages du noyau et la documentation correspondante.
Puis-je installer un pilote trouvé sur GitHub ?
Pas comme solution générale. Un dépôt ou un script communautaire peut viser une puce, un noyau ou un board précis et comporter des risques. Ne l’installez pas sans correspondance documentée avec votre matériel et sans comprendre les changements ; privilégiez les paquets officiels Ubuntu.
Quand dois-je arrêter les essais ?
Quand le board ou la puce ne sont pas identifiés, quand le support de l’architecture ou du board n’est pas documenté, ou quand aucune solution officielle ne correspond aux erreurs relevées. Dans ces cas, évitez flash, pilotes et firmwares improvisés et demandez conseil avec des diagnostics expurgés.