Skip to content

Linux Troubleshooting

Le Khanh Binh edited this page Jun 29, 2026 · 4 revisions

Linux Troubleshooting

Check the daemon logs before anything else — they usually tell you what's wrong.


Reading the daemon logs

journalctl -u uxtu4linux.service -n 100 --no-pager

For a live stream:

journalctl -u uxtu4linux.service -f

Every preset apply is logged with its trigger:

Applied preset 'Eco' (power source changed from AC to battery).
Applied preset 'Gaming' (selected in the app).
Applied preset 'Balance' (restoring saved settings at startup).

For more detail, enable debug logging (toggle Debug in Settings, or edit config directly):

# Assets/config.ini
[Settings]
debug = 1

Then restart the daemon:

sudo systemctl restart uxtu4linux.service

Daemon issues

Daemon is not running / TUI says "Not running"

With systemd — try starting it:

sudo systemctl enable --now uxtu4linux.service

Check the status:

systemctl status uxtu4linux.service

Full logs:

journalctl -u uxtu4linux.service -n 50 --no-pager

Without systemd — start the daemon by hand (needs root):

sudo /opt/uxtu4linux/venv/bin/python3 /opt/uxtu4linux/src/Assets/daemon/daemon.py
Log message Fix
ryzen_smu not installed. Required when Secure Boot is enabled. Secure Boot is on and ryzen_smu is missing — install it, see Linux Installation §2
ryzen_smu version X.X.X is too old (minimum: 0.1.7). Update ryzen_smu, same guide
ryzen_smu not signed for Secure Boot. Enroll the signing key, see the Secure Boot section below
ryzen_smu installed but not loaded. Run sudo modprobe ryzen_smu then restart the service
Secure Boot disabled — using PCI direct access backend. Normal startup message — no action needed, PCI backend is active
PCI backend unavailable — presets will not be applied. PCI config path /sys/bus/pci/devices/0000:00:00.0/config is missing or not writable as root — unexpected, file a bug
dmidecode not found in PATH - hardware detection unavailable. Install dmidecode for your distro
Another daemon instance is already running (lock: /run/uxtu4linux_daemon.lock). A previous daemon instance is still running. Kill it: sudo pkill -f daemon.py
Cannot bind IPC socket ipc:///run/uxtu4linux.sock: The socket may be stale or held by another process. Run sudo rm /run/uxtu4linux.sock then restart the service
Cannot remove stale socket /run/uxtu4linux.sock: Permission problem on the socket file. Run sudo rm /run/uxtu4linux.sock then restart the service

"Version mismatch" warning on startup

Usually happens after an update where the daemon wasn't restarted. Fix:

sudo systemctl restart uxtu4linux.service

Without systemd, kill the daemon process and start it again:

sudo pkill -f daemon.py
sudo /opt/uxtu4linux/venv/bin/python3 /opt/uxtu4linux/src/Assets/daemon/daemon.py

Daemon starts but exits immediately

Check logs. If you see Cannot bind IPC socket or Cannot remove stale socket:

sudo rm /run/uxtu4linux.sock
sudo systemctl restart uxtu4linux.service

Python tracebacks mean something is broken in the install. Quickest fix:

curl -fsSL https://raw.githubusercontent.com/HorizonUnix/UXTU4Linux/main/install.sh | bash

Service keeps restarting / flapping

The unit has Restart=on-failure, RestartSec=5. Check logs to see why it's crashing — the fix depends on the error.

To stop the restart loop and see daemon output directly:

sudo systemctl stop uxtu4linux.service  # or kill it however your init handles it
sudo /opt/uxtu4linux/venv/bin/python3 /opt/uxtu4linux/src/Assets/daemon/daemon.py

TUI can't connect after the daemon is running

Check the socket exists:

ls -la /run/uxtu4linux.sock

If it's missing, the daemon isn't fully started yet. Wait a few seconds.

If it exists but the TUI still can't connect, check permissions. Should be world-writable (daemon sets 666 on it at startup):

stat /run/uxtu4linux.sock

ryzen_smu issues

Note

ryzen_smu is only needed when Secure Boot is on. With Secure Boot off, the daemon uses PCI direct access and none of this applies.

ryzen_smu is not installed

Daemon starts but logs ryzen_smu not installed. Required when Secure Boot is enabled. and presets don't apply. See Linux Installation §2 for full per-distro steps.

Quick version:

# Install build dependencies first (this example is Debian/Ubuntu)
sudo apt install cmake gcc g++ dkms openssl

# Build and install
git clone https://github.com/amkillam/ryzen_smu
cd ryzen_smu
sudo make dkms-install
sudo modprobe ryzen_smu

ryzen_smu version is too old

Minimum is 0.1.7. Check:

cat /sys/kernel/ryzen_smu_drv/drv_version

To update:

cd ryzen_smu    # your existing clone, or clone it fresh
git pull
sudo make dkms-uninstall   # remove the old version from DKMS
sudo make dkms-install     # install the new version
sudo modprobe -r ryzen_smu
sudo modprobe ryzen_smu

modprobe fails with "Operation not permitted"

Secure Boot is on and the module isn't signed. See the Secure Boot section below.


modprobe fails with "Module ryzen_smu not found"

Module isn't installed for the running kernel. Common causes: kernel updated and DKMS didn't rebuild, headers missing, or installed for a different kernel.

Check DKMS status:

sudo dkms status

ryzen_smu/X.X.X: added but not installed means you need to force a rebuild:

sudo dkms install ryzen_smu/$(sudo dkms status | grep ryzen_smu | cut -d, -f1 | cut -d/ -f2)

Or just reinstall from source:

cd ryzen_smu
sudo make dkms-uninstall
sudo make dkms-install
sudo modprobe ryzen_smu

ryzen_smu loads but /sys/kernel/ryzen_smu_drv/ is missing or empty

sudo modprobe -r ryzen_smu
sudo modprobe ryzen_smu
dmesg | tail -20

Check dmesg for module errors. If the directory is empty after loading, your CPU may not be supported by the installed version of ryzen_smu.


Secure Boot issues

Module won't load with Secure Boot enabled

Secure Boot on means the kernel only loads signed modules. Enroll the DKMS signing key:

mokutil --sb-state

Enroll the key:

sudo mokutil --import /var/lib/dkms/mok.pub

Set a one-time password when prompted, then reboot. Watch for the blue MOK Manager — it only stays a few seconds:

  1. Enroll MOKContinueYes
  2. Type the one-time password
  3. Reboot

After booting:

sudo modprobe ryzen_smu
lsmod | grep ryzen_smu

MOK Manager screen didn't appear

Either the timeout was too short and you missed it, or your firmware doesn't support MOK enrollment. Try mokutil --import /var/lib/dkms/mok.pub again and reboot. If it still doesn't appear, check BIOS for "Secure Boot Key Management", "MOK Management" or "UEFI Key Enrollment".


Secure Boot is enabled and you can't enroll the key

Some OEM laptops have Secure Boot locked down. Options:

  1. Disable Secure Boot in BIOS/UEFI and reload the module
  2. Use a distro-packaged signed kernel module if one exists
  3. Build and sign with your own key and add it to the UEFI Authorized Signature Database (advanced)

Hardware detection issues

Hardware type shows "Unknown"

CPU was detected but has no SMU command table. Could be: CPU is pre-Zen 1, too new to be added yet, or dmidecode returned incomplete info.

Try Settings → Re-detect hardware first.

If still Unknown:

sudo dmidecode -t processor

Check the Family and Model fields. If they look right, file a bug with that output and your CPU model name.


CPU detected as wrong family or codename

Run Settings → Re-detect hardware. If the wrong codename persists, it's a bug in detection logic — file a bug with your CPU model and:

sudo dmidecode -t processor | grep -E "Version|Signature|Family|Model"

Hardware detection fails because the daemon isn't running

Detection proxies dmidecode through the daemon (it needs root). Start the daemon first:

sudo systemctl enable --now uxtu4linux.service

Then retry from Settings → Re-detect hardware.


dmidecode returns empty or incorrect data

Incomplete DMI tables are a firmware bug. Try updating BIOS/UEFI, or check if your distro has a newer dmidecode. If it genuinely can't get CPU info, the app falls back to Unknown with limited functionality.


Preset issues

Presets apply but the CPU reverts after a few seconds

Something else is resetting the power limits — common culprits are power-profiles-daemon, thermald, tlp, auto-cpufreq. Enable Reapply in Settings with a short interval:

Settings (7) → Reapply preset periodically on → Reapply interval = 3


Presets reset after sleep/resume/hibernation

The SMU loses state on suspend. Set a resume preset:

Automations (4) → Preset on System Resume → pick a preset

The daemon detects resume by comparing CLOCK_BOOTTIME against time.monotonic(), so it catches both suspend-to-RAM and hibernation with no dependency on logind. You'll see Applied preset 'Balance' (woke from suspend after ~28m). in the logs.

If the resume preset never applies: either CLOCK_BOOTTIME isn't available (daemon logs this and disables detection), or resume is restarting the service — in that case enable Apply preset on daemon start in Settings instead.


Automations aren't switching on AC/battery

At least one of Preset on Battery Charge or Preset on Battery Discharge needs to be set. There's no separate on/off switch.

Check the daemon is running:

systemctl is-active uxtu4linux.service

Check power source:

cat /sys/class/power_supply/AC*/online 2>/dev/null || cat /sys/class/power_supply/ACAD*/online 2>/dev/null

1 = AC, 0 = battery. If the file doesn't exist, the kernel isn't reporting AC state and the monitor can't see transitions.


Applied preset has no effect on performance

Open the Status tab (6) and check for rejected commands (marked [!]). Other possibilities: the CPU is throttling for thermal or VRM reasons, or your CPU family doesn't support a parameter — lines like some-arg -> not supported on HawkPoint in the apply output mean exactly that.


Custom preset shows no sections / editor is mostly empty

The editor only shows sections for parameters the CPU's SMU firmware supports. If almost everything is hidden, the CPU may be mapped to a socket type with limited command support.

Check detected family:

grep -i family /opt/uxtu4linux/src/Assets/config.ini

If Unknown or wrong, fix detection first. If correct but sections are still missing, it's a genuine limitation of that CPU's SMU firmware.


Config and setup issues

Setup wizard runs every time I start the app

The Info section in config.ini is missing or incomplete — usually after a bad update, manual config editing that removed required keys, or a first run that got interrupted. Let the wizard run to completion and don't skip hardware detection; Info only gets written when detection finishes.


All my settings and custom presets were wiped

If you hit Reset all in Settings, that's intentional. If it happened on its own, the Info section was broken and the wizard reset the config.

Custom presets live in Assets/custom.json. Updates back it up to /opt/uxtu4linux/custom.json.bak — restore with:

cp /opt/uxtu4linux/custom.json.bak /opt/uxtu4linux/src/Assets/custom.json

config.ini is not being saved

Check Assets/ is writable by the user running the TUI:

ls -la /opt/uxtu4linux/src/Assets/

The install script chowns /opt/uxtu4linux to your user. If you installed manually with sudo, fix it:

sudo chown -R "$USER" /opt/uxtu4linux/src

Display and terminal issues

"Terminal too small" message

Needs at least 50×25. Make the window bigger or reduce font size — the UI comes back automatically.


Garbled characters or weird symbols

Needs UTF-8 and a terminal with ANSI/truecolor support. Most modern terminals handle this fine.

Check locale:

echo $LANG

Should be en_US.UTF-8 or similar. If it's C or POSIX:

export LANG=en_US.UTF-8

Colors look wrong or input doesn't work over SSH

Check TERM:

echo $TERM

If it's dumb or empty:

export TERM=xterm-256color

Inside tmux or screen, use tmux-256color so colors render correctly.


App won't start outside a real terminal

Needs an interactive terminal — no piped input, scripts or non-interactive shells. Run it directly in a terminal emulator. In tmux or screen, make sure you're attached to a live session.


Service path issues

Daemon starts but uses the wrong Python or the wrong script path

The service file bakes in absolute paths at install time. If you moved the app, the paths go stale. Launch the TUI once — it checks the service file and rewrites it automatically if paths don't match:

uxtu4linux

If that doesn't work, regenerate manually:

sudo systemctl stop uxtu4linux.service
sudo tee /etc/systemd/system/uxtu4linux.service > /dev/null << 'EOF'
[Unit]
Description=UXTU4Linux Power Management Daemon
After=multi-user.target

[Service]
Type=simple
ExecStart=/opt/uxtu4linux/venv/bin/python3 /opt/uxtu4linux/src/Assets/daemon/daemon.py
Restart=on-failure
RestartSec=5
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl start uxtu4linux.service

Update issues

Update fails with a permission error

The updater uses sudo mv internally. If sudo isn't available or the prompt fails, it aborts with "Could not back up ... try running with sudo". Re-run the install script to recover:

curl -fsSL https://raw.githubusercontent.com/HorizonUnix/UXTU4Linux/main/install.sh | bash

Update completed but the app is broken / won't start

Config and presets are backed up to /opt/uxtu4linux/config.ini.bak and custom.json.bak (the updater restores them on success). If the new version is broken, re-run the installer:

curl -fsSL https://raw.githubusercontent.com/HorizonUnix/UXTU4Linux/main/install.sh | bash

If an update died halfway, the old app dir may be at /opt/uxtu4linux/src.bak:

sudo rm -rf /opt/uxtu4linux/src
sudo mv /opt/uxtu4linux/src.bak /opt/uxtu4linux/src
sudo systemctl restart uxtu4linux.service

Getting more help

Collect this before opening an issue:

# OS and kernel
uname -a
cat /etc/os-release

# Python version
python3 --version

# ryzen_smu version
cat /sys/kernel/ryzen_smu_drv/drv_version 2>/dev/null || echo "not loaded"

# CPU info
sudo dmidecode -t processor | grep -E "Version|Signature|Family|Model|Manufacturer"

# Daemon logs
journalctl -u uxtu4linux.service -n 50 --no-pager

# App config
cat /opt/uxtu4linux/src/Assets/config.ini

Open an issue on GitHub with this output and a description of what you were doing.

Clone this wiki locally