Native Ubuntu or Crostini: Check Environment and Model Limitations
This guide concerns a Chromebook that boots directly into Ubuntu, installed as the primary system or in native boot. It does not apply to Crostini: in this Linux environment launched from ChromeOS, devices are presented differently and Ubuntu does not directly control the Wi-Fi card or internal speakers. If you are in the Linux terminal of ChromeOS, stop here and seek help specific to Crostini.
Sound and Wi-Fi may fail simultaneously, but they often have independent causes. The former may depend on the selected output, audio stack, or controller; the latter, on the radio, driver, or firmware. They are diagnosed separately, without assuming that a single fix will solve both.
Before making any changes, back up your important files and ensure you can return to a functional system. Note the version of Ubuntu, the kernel, and the architecture:
grep '^PRETTY_NAME=' /etc/os-release
uname -r
uname -mThese commands respectively display the distribution, kernel version, and architecture. An x86_64 architecture alone does not guarantee that the Chromebook is supported. aarch64 or arm64 requires verifying documentation specific to the device; the MrChromebox list mentioned below pertains to supported Intel/AMD x86_64 devices, not to ARM Chromebooks.
Identify the board name or exact HWID in a reliable model documentation. The brand name—even if it refers to a known range—is not sufficient to establish compatibility. If the board is not documented for the intended use, or if you cannot identify it, stop testing drivers and firmware. The Ubuntu installation and compatibility guide for Chromebook helps distinguish precautions taken before installation from the diagnostics presented here, which occur after native boot.
Inventory the Wi-Fi Card and Audio Controller Separately
Start with the tools already present. lspci -nnk displays PCI devices with their identifiers in brackets, along with associated drivers and modules. lsusb inventories USB devices, including an external network adapter. If inxi is already installed, inxi -Nxxx can detail the network section. Do not install a driver to perform this inventory.
lspci -nnk
lsusbIn the result from lspci, “Kernel driver in use” designates the driver actually attached to the device; “Kernel modules” indicates candidate modules, not proof that a driver is functioning. Note separately the identifier and name of the network card and audio controller. If a command does not exist, move to those that are available: absence is not a hardware diagnostic.
Do not conclude that a card is absent solely based on lspci. Some embedded elements are not exposed as PCI or USB devices. Cross-reference the inventory with logs and board documentation before deciding.
Wi-Fi: Is the Radio Blocked, Interface Absent, or Just Disconnected?
First, check the status of the radio and interface. These commands do not modify the configuration:
rfkill list
nmcli device status
ip linkrfkill list indicates whether a device is “Soft blocked” or “Hard blocked.” A software block can be lifted by the system; a hardware block corresponds to a physical command or a condition imposed by the device. Do not bypass the latter. Check the hardware control or documented procedure for the board.
nmcli device status shows the status seen by NetworkManager. A disconnected Wi-Fi interface is detected but is not connected: attempt a normal connection from the network settings, then inspect the network or router if necessary. unavailable, unmanaged or the absence of an interface rather suggests examining the driver, service, and kernel. The name of the interface varies: do not assume it is called wlan0.
ip link completes this check by listing the network interfaces. Its absence does not prove, by itself, that the physical card does not exist: the driver may not have registered it, or the device may not appear on this bus. Cross-reference this result with lspci -nnk, lsusb, and the logs.
Use nmcli radio wifi on only if the diagnosis confirms the radio is disabled or there is a software block present. You can also reactivate Wi-Fi in the Ubuntu settings. Then check rfkill list and nmcli device status again. This command does not lift a hardware block and does not create a missing driver.
Read Kernel Logs Without Modifying the System
Search for messages associated with the names of drivers actually spotted and with the terms firmware, Wi-Fi, and audio. The following two commands are read-only and filter their output to remain readable on a mobile screen:
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'If dmesg denies access, an administrator may relaunch the read with sudo dmesg -T. Reading journalctl may also require permissions on certain installations. Do not send a complete log without purging it: remove MAC addresses, serial numbers, and other personal identifiers.
An error naming a missing firmware file, an initialization failure, or a driver attaching are clues to confront with the hardware identifier, kernel version, and board documentation. No filtered line proves by itself that the hardware is supported. iwlwifi messages relate to Intel chips compatible with this driver, not all Wi-Fi cards; sof and snd mentions lead to the audio section and should be read separately.
An update of Ubuntu firmware is justified only if the logs name a missing firmware, the chip and board are identified, an alternative connection is available, and the official Ubuntu package corresponds to your installation. Only in this case, back up first, review the relevant log, then use the Ubuntu repositories:
sudo apt update
sudo apt install --reinstall linux-firmwareDo not run these commands as a general trial: reinstalling linux-firmware is not a guarantee of support, and not all chips rely on this package. After the installation, read the kernel messages again to check if the identified error has changed. Reboot only after saving and closing your work. If no documented official package corresponds to the named firmware, stop: do not copy an upstream file and do not randomly replace the driver.
No Sound: Check Output Before Controller
Start with Settings > Sound: check that the output is not muted, cautiously raise the volume, and select the expected device. Ubuntu may send sound to HDMI, a headset, or a Bluetooth device rather than the internal speakers. If an output is available, use the speaker test in the settings at low volume. If sound comes from another output, the problem primarily lies with routing, not with replacing firmware.
Then check the audio devices seen by the available tools:
aplay -l
wpctl statusaplay -l lists ALSA cards and devices when the tool is installed. “No soundcards found” points to absent detection or driver rather than simply volume adjustment. wpctl status, if your session uses PipeWire and wpctl is available, shows the audio outputs of the session and which one is selected. Its absence does not prove that the hardware controller is absent.
If ALSA sees a card but PipeWire does not offer a usable output, examine the audio session and service before any action. Avoid blind restarts. If no card appears, cross-reference lspci -nnk with sof or snd messages from the logs. An absent controller from the inventory cannot be fixed just by changing the output; a controller present with HDMI or headset selected primarily involves routing.
Backup Internet and Stopping Criteria
If Wi-Fi is not working, a recognized USB Ethernet adapter or USB tethering can provide temporary access. Use it to gather diagnostics and, only if the missing firmware has been identified, obtain official Ubuntu updates. This backup network allows you to continue the investigation; it does not repair the internal Wi-Fi card.
Stop testing if the board name/HWID remains unknown, if the architecture or board lacks documented support, if the kernel does not see the device after verification, or if no official driver or firmware corresponds to the hardware identifier. To request help, provide the verified board/HWID, architecture, Ubuntu and kernel versions, network and audio identifiers, the states of rfkill and nmcli, and only the relevant filtered log excerpts. Also specify what still works. A simultaneous failure of sound and Wi-Fi is not sufficient to establish a common cause.
Frequently Asked Questions
Why does Wi-Fi work on ChromeOS but not on Ubuntu?
Both systems may use different drivers, a kernel, or firmware. This alone does not conclude that a Ubuntu driver exists for your chip. Identify the hardware ID and board, then check kernel messages and corresponding documentation.
Can I install a driver found on GitHub?
Not as a general solution. A community repository or script may target a specific chip, kernel, or board and carry risks. Do not install it without documented correspondence with your hardware and without understanding the changes; prioritize official Ubuntu packages.
When should I stop testing?
When the board or chip are not identified, when the support for the architecture or board is not documented, or when no official solution corresponds to the highlighted errors. In these cases, avoid flashing, non-official drivers, and improvised firmwares and seek advice with purged diagnostics.
Sources
- Ubuntu Desktop Guide — Troubleshooting Wireless Networking
- Ubuntu Desktop Guide — No Sound
- Linux Wireless — iwlwifi
- MrChromebox — Supported Devices
