TUXEDO Tomte Light: A new Multi-Distro Tool for Hardware Fixes - TUXEDO Computers

Our TUXEDO penguins prepared a small gift for you for this year's Christmas season: TUXEDO Tomte Light, a lightweight, cross-distribution utility for applying our TUXEDO fix and board packages.

While TUXEDO Tomte was originally developed exclusively for Ubuntu LTS and operates there on a clearly defined whitelist, TUXEDO Tomte Light follows a more opportunistic, package-based approach. It was created to provide hardware-related adjustments on all systems where Tomte is not available – including Ubuntu point releases, Debian-based derivatives, and several rpm- and zypper-based distributions.

Supported distributions

TUXEDO Tomte Light is now available for:

• Debian-based systems where Tomte does not run e.g., Ubuntu 25.10, Debian Testing, siduction
• Fedora (from version 43)
• openSUSE Leap and Tumbleweed

Planned in perspective

• Arch Linux
• additional pacman-based distributions

Support will be expanded as soon as all required packages are available.

What does TUXEDO Tomte Light do?

TUXEDO Tomte Light:

• detects the installed TUXEDO model based on board data
• automatically installs the appropriate TUXEDO fix packages
• supports the board meta packages currently in development
• works fully package-based, without scripts or direct system modifications
• is ideal for WebFAI, automated installations, and QA testing

This provides a unified, reproducible, and testable way to roll out our hardware adjustments across far more distributions than before.

Board meta packages: current development status

The board meta packages are currently being set up. They will be gradually made available for those devices that require specific fixes.

Once a board meta package becomes available for a device:

➡️ TUXEDO Tomte Light automatically detects it
➡️ and installs all recommended fix packages

This establishes a clear, portable, and easily maintainable structure for device-specific adjustments over the long term.

What is explicitly not part of the functionality?

TUXEDO Tomte Light intentionally remains minimalistic. Not included:

• NVIDIA / hybrid-GPU-specific configurations
• removing or cleaning up old kernels
• driver updates outside the fix packages
• executing shell scripts
• selectively blocking or removing individual fixes
• an extensive CLI (kept deliberately minimal)

How do I install TUXEDO Tomte Light?

The packages are already available on GitLab. Starting early next week, TUXEDO Tomte Light will be delivered through the official TUXEDO software repositories.

Support is always provided for the latest distribution versions (e.g. Fedora 43).
 

Tekkie Corner – under the Hood of TUXEDO Tomte Light

Implementation & dependencies

• Implemented in Python with a modern project structure pyproject.toml, relies on a current Python version, and uses PyYAML for configuration processing.
• A central logging setup separates INFO/DEBUG to STDOUT and WARN/ERROR/CRITICAL to STDERR.

Hardware detection

• Hardware data is collected using lspci -n and lsusb with timeouts.
• PCI and USB devices are then read directly from /sys/bus/pci/devices and /sys/bus/usb/devices and merged into normalized vendor:device IDs in hex format.
• Additionally, the number of GPUs is determined by counting PCI devices with the corresponding class code.

Startup, retry, and error behavior

• By default, TUXEDO Tomte Light is executed:

• 5–10 minutes after system startup,

• then every 12 hours afterwards.

• In cases of ungraceful exits – e.g. when:

• no internet is available,

• the package manager is locked,

• a timeout occurs – → the run is automatically retried up to two times, → each with a 30-minute delay.

This ensures that fix and board packages can be installed even under difficult network or package-manager conditions.

Rule engine & configuration layers

• The configuration is loaded from multiple YAML layers, e.g.:

• base.yaml

• optional tuxedo-devices.yaml (device-specific)

• optional tuxedo-os.yaml (OS-specific)

• Which layers are active depends on whether:

• the system is detected as a TUXEDO device (DMI strings),

• and/or a TUXEDO OS is running /etc/os-release.

• The YAML structure describes conditions such as:

• lists of PCI IDs

• lists of USB IDs

• minimum GPU count GPU_COUNT_min

• A validation step ensures that the configuration is formally correct before it is used.

Matching logic & package mapping

• From the collected hardware data, all relevant device IDs are matched against the configuration rules (PCI/USB/GPU_COUNT) using regular expressions.
• The result is a set of abstract package names (fix or meta packages) that are not yet distribution-specific.
• A mapping table package_mapper.yaml translates these package names – if necessary – based on ID and ID_LIKE from /etc/os-release into concrete package names for the respective distribution.
• Packages already marked as installed are filtered out before installation.

Board detection & board meta packages

• DMI information /sys/class/dmi/id/board_name and board_vendor is read and transformed by a filter into a valid package-name form (only allowed characters, normalized spelling).
• From this, meta package names such as tuxedo-board- and tuxedo-board-vendor- are derived.
• Existing board meta packages are installed together with the hardware-based fix packages, integrating them automatically as soon as they become available.

Package manager abstraction

• An abstract PackageManager class encapsulates system calls and normalizes logging, exit codes, and output.

• Concrete implementations exist for:

• apt-get (Debian/Ubuntu world)

• dnf (Fedora)

• zypper (openSUSE)

• pacman (Arch)

• The active package manager is determined automatically based on available binaries, with defined priority and explicit per-package existence checks (e.g. via apt-cache policy, rpm/dnf repoquery, zypper search).

State management

• Installation state is stored under /var/lib/tuxedo-tomte-light/state/installed.
• For each installed package, a flag file with a timestamp is created to prevent repeat or unnecessary installation attempts.
• Using –reset, this state can be reset; with –force, flags are removed and the process is started again immediately.

Altogether, this results in a small, clearly scoped engine that:

• deterministically detects hardware
• evaluates rules from YAML layers
• maps packages per distribution
• works exclusively via native package managers
• stores its own state transparently

Happy Holidays and lots of joy with Tomte Light from the TUXEDO penguins