Behind the scenes of Tomte 3 - TUXEDO Computers

With TUXEDO Tomte 3, we are introducing the next evolutionary step of our cross-distribution configuration tool. The new version features a significantly more modular architecture, reduces operational complexity, and consistently delegates many decisions to the package management of the respective system.

Development History: From Tomte to Tomte Light

Tomte 3 is the direct successor to TUXEDO Tomte Light. While the original Tomte was developed exclusively for Ubuntu LTS with a clearly defined device whitelist, Tomte Light already pursued a generic, package-based approach to support additional distributions.

This brought initial support for Ubuntu Point Releases, Debian derivatives, and RPM- and Zypper-based systems — though still with growing maintenance overhead in the background. Tomte 2 performed its duties reliably, but ran into structural limitations due to the sheer number of distribution-specific implementations. This is precisely where Tomte 3 steps in: less special-case logic, more standardization.

Architecture Under the Hood

Tomte 3 is implemented entirely in Python and follows a modern project structure based on pyproject.toml. PyYAML is used for configuration processing.

Hardware detection works at the system level via:

• lspci -n for PCI devices
• lsusb for USB devices
• direct evaluation of /sys/bus/pci/devices and /sys/bus/usb/devices

The detected devices are normalized into a unified ID format (vendor:device) and then matched against the configuration layers.

Multi-Layer Configuration

The configuration is deliberately modular and follows a layered model:

• base.yaml — fundamental rules
• tuxedo-devices.yaml — hardware-dependent definitions
• tuxedo-os.yaml — distribution-specific adjustments

Which layers become active depends on two factors:

• Detection via DMI strings (TUXEDO hardware)
• Detection of a TUXEDO OS

DMI-based packages and adjustments are checked on every run and applied as needed.

Package Manager Abstraction

A core element of Tomte 3 is its abstracted package management. A shared PackageManager layer encapsulates:

• Logging
• Exit codes
• Output formats

Currently supported package managers:

• apt-get
• dnf
• zypper
• pacman

Selection happens automatically based on the binaries available on the system.

NVIDIA Handling and Differences from Tomte Light

Unlike Tomte Light, Tomte 3 integrates a revised nvidia-driver-assistant. Systems with NVIDIA graphics are detected more accurately, and the necessary initial steps are carried out automatically.

Importantly, this initial configuration happens only once. After that, responsibility passes entirely to the system’s own package management.

Switch to Standard NVIDIA Packages

Tomte 3 also modernizes the packaging strategy. Instead of distribution-specific package names like tuxedo-nvidia-580-open, standard NVIDIA driver packages are now used — combined with a pinning mechanism.

Example:

sudo apt install nvidia-driver-pinning-[Version]

The recommended default configuration is provided via tuxedo-nvidia-driver-default-pinning.

Removing all pinning packages will allow newer driver versions to be installed automatically, provided they have not yet been rolled out system-wide within the current release cycle.

Board Meta and Fixes Packages

The package structure already prepared in Tomte Light has been fully adopted and standardized in Tomte 3.

Instead of monolithic device profiles, there is now a clear separation:

• Board meta packages define which optimizations are required for a given hardware platform
• Fixes packages contain the concrete measures and adjustments

This split enables targeted, modular updates independent of distribution and release cycles.

Kernel Parameters: New Management Layer

In Tomte 2, kernel parameters were set or removed by directly manipulating /etc/default/grub via regex.

Tomte 3 takes a considerably cleaner approach:

• Kernel parameters are provided through fixes packages
• They are stored in /etc/default/grub.d/
• Existing user configurations remain untouched

This prevents individual customizations from being overwritten.

Clean GRUB Migration

Existing GRUB configurations are migrated in a one-time process:

• existing CMDLINE entries in /etc/default/grub are commented out
• deviations are documented
• a new, optimized configuration is added

This process is deliberately conservative to ensure stable migration of existing systems.

Update Strategy and System Integration

Tomte 2 regularly installed packages such as:

• NVIDIA drivers
• linux-tuxedo
• tuxedo-drivers

and actively kept them at a defined version.

Tomte 3 significantly reduces these interventions:

• USB/PCI fixes are installed once only
• Updates are handled exclusively by the system package manager
• no repeated enforcement of kernel or driver versions

This makes the system more consistent and less invasive over time.

Simplified Interface and CLI Reduction

Tomte 3 reduces the codebase to roughly one tenth of its previous size. The command-line interface has been significantly streamlined.

Only two commands remain:

sudo tuxedo-tomte --reset
sudo tuxedo-tomte --force

• –reset resets the internal state and allows a full re-evaluation of all measures
• –force lifts internal lock mechanisms and forces a new run

Summary

TUXEDO Tomte 3 reduces complexity on multiple levels: architecture, package logic, and system intervention. For developers, this means significantly easier maintainability across distributions. For users, it means a largely autonomous system maintenance tool that only intervenes during initial setup and thereafter trusts the system’s own package management. Those who prefer to opt out of this automatic maintenance can remove Tomte at any time — without any impact on the rest of the system configuration.