btop GPU Missing: Check GPU_SUPPORT, Drivers, and Permissions

Identify which boundary is failing#

Start by recording the binary and testing the same command as your normal user and, only for diagnosis, with sudo:

1
command -v btop
2
btop --version
3
btop
4
sudo -n btop

Do not leave the root session running as the permanent fix. The comparison is useful because it separates an access problem from a missing build dependency or unsupported hardware path.

The upstream btop README is the source of these support boundaries. Treat the table as a routing tool, not as proof that every distribution package has the same feature set.

Check the binary’s distribution boundary first#

The current upstream README says that binaries from the release page and continuous builds do not have GPU support enabled. That means btop can start normally while the GPU panel is absent; a working vendor tool such as nvidia-smi does not change a binary that was built without GPU_SUPPORT.

Record where the running binary comes from before changing drivers or permissions:

1
command -v btop
2
btop --version

If the binary came from an upstream archive without GPU support, use a package that explicitly documents the feature or build btop from source with the flag enabled. Do not treat a version upgrade as a GPU-support upgrade unless the package’s build options say so.

Confirm that the binary has GPU support#

btop’s upstream documentation says GPU monitoring on Linux requires a binary built with GPU support. For a source build, make that feature explicit instead of relying on the package’s defaults:

1
git clone https://github.com/aristocratos/btop.git
2
cd btop
3
make GPU_SUPPORT=true
4
sudo make install

The exact build toolchain and optional libraries still depend on the GPU vendor. A successful compile does not guarantee that btop can query a GPU at runtime, so check the matching dependency next.

1
nvidia-smi
2
ldconfig -p | grep -i nvidia-ml

1
command -v rocm-smi || true
2
ldconfig -p | grep -i rocm

Check permissions without making sudo the solution#

Intel GPU monitoring and CPU wattage are the two cases where the upstream instructions explicitly call out additional access setup. The source installation flow documents make setcap as the preferred option, with make setuid or running btop with sudo as alternatives.

For a source installation, run the capability step after make install and use the same PREFIX if you installed into a custom directory:

1
sudo make setcap

Then start a new normal-user session and run btop again. If you installed from a distribution package, do not copy a source-build command blindly. First inspect the package’s policy and the actual binary path:

1
command -v btop
2
getcap "$(command -v btop)" 2>/dev/null || true

The distinction matters because file capabilities are part of how the binary is installed and maintained. A Debian bug report about btop GPU statistics records an open packaging discussion rather than a universal command that applies to every Debian-based system. That is a reason to check the package’s current guidance, not a reason to grant a broad capability without review.

An upstream issue also documents an Intel integrated GPU that appeared for root but not for the regular user. That is useful evidence for the diagnosis pattern, but it does not prove that the same capability or path is correct for your hardware. Use root only to confirm the boundary, then apply the smallest supported access change for your installation method.

Select a real CPU temperature sensor#

Temperature is a separate path from GPU access. btop’s configuration exposes cpu_sensor so you can select one of the sensors detected by the system. If the list is empty or the values are obviously wrong, inspect the sensor layer first:

1
sensors

If the command is unavailable, install and configure the lm-sensors package using your distribution’s documentation. If it runs but does not expose a CPU package or core sensor, btop cannot select a value that the operating system has not made available. If several candidates exist, open btop’s options and choose the sensor that matches your hardware instead of assuming Auto is correct.

The upstream configuration describes both check_temp and cpu_sensor, and its issue tracker shows why sensor names matter: btop searches for known names and can fall back when the expected CPU sensor is absent. A blank temperature is therefore not automatically a btop rendering bug.

Verify the fix in the same environment#

After changing a build, driver library, capability, or sensor choice, verify the result as the account that will actually use btop:

1
id
2
command -v btop
3
btop --version
4
getcap "$(command -v btop)" 2>/dev/null || true
5
sensors 2>/dev/null || true
6
nvidia-smi 2>/dev/null || true

Then open btop without sudo and check one metric at a time:

1. Does the GPU section exist?
2. Does the vendor’s independent tool see the GPU?
3. Does the metric appear only as root?
4. Does a different CPU sensor produce a plausible temperature?
5. Does the value remain after opening a new terminal or logging in again?

This order prevents an access change from hiding a missing driver library, and it prevents a sensor-selection change from being mistaken for a GPU fix. If the metric still fails, keep the output of btop --version, the package source, the GPU vendor, and the non-root/root comparison together when reporting the problem.

The practical rule is to treat a missing btop metric as a support, dependency, sensor, or permission boundary. Confirm which boundary you have first, then fix only that layer; running the whole monitor as root should remain a diagnostic comparison rather than the operating model.

FAQ#