TUXEDO Tomte Light: Ein neues Multi-Distro-Werkzeug für Hardware-Fixes - TUXEDO Computers

Der Nikolaus bringt dieses Jahr ein besonderes neues Werkzeug für Linux-Nutzerinnen und -Nutzer mit: TUXEDO Tomte Light, ein leichtgewichtiges, distributionsübergreifendes Tool zur Anwendung unserer TUXEDO Fix- und Boardpakete.

Während TUXEDO Tomte ursprünglich ausschließlich für Ubuntu LTS entwickelt wurde und dort auf einer klar definierten Whitelist arbeitet, verfolgt TUXEDO Tomte Light einen opportunistischeren und paketbasierten Ansatz.
Es wurde entwickelt, um hardwarebezogene Anpassungen auf all jenen Systemen bereitzustellen, auf denen Tomte nicht zur Verfügung steht – einschließlich Ubuntu Point Releases, Debian-basierten Derivaten und mehreren rpm- und zypper-basierten Distributionen.

Verfügbare Distributionen

TUXEDO Tomte Light steht ab sofort bereit für:

• Debian-basierte Systeme, auf denen Tomte nicht läuft, z. B. Ubuntu 25.10, Debian Testing, siduction
• Fedora (ab Version 43)
• openSUSE Leap und Tumbleweed

Perspektivisch geplant

• Arch Linux
• weitere Pacman-basierte Distributionen

Die Unterstützung wird erweitert, sobald alle benötigten Pakete bereitstehen.

Was macht TUXEDO Tomte Light?

TUXEDO Tomte Light:

• erkennt das verbaute TUXEDO-Modell anhand der Board-Daten
• installiert automatisch die passenden TUXEDO Fixpakete
• unterstützt die in der Entwicklung befindlichen Board-Metapakete
• arbeitet vollständig paketbasiert, ohne Skripte oder direkte Systemmodifikationen
• ist ideal für WebFAI, automatisierte Installationen und QA-Testzwecke

Damit stellt TUXEDO Tomte Light einen einheitlichen, reproduzierbaren und testbaren Weg bereit, unsere Hardware-Anpassungen über viel mehr Distributionen als bisher hinweg auszurollen.

Board-Metapakete: aktueller Entwicklungsstand

Die Board-Metapakete befinden sich derzeit im Aufbau.
Sie werden nach und nach für jene Geräte bereitgestellt, die spezielle Fixes benötigen.

Sobald ein Board-Metapaket für ein Gerät verfügbar ist:

➡️ erkennt TUXEDO Tomte Light dieses automatisch
➡️ und installiert alle empfohlenen Fixpakete

So entsteht langfristig eine klare, portable und gut wartbare Struktur für gerätespezifische Anpassungen.

Was gehört ausdrücklich nicht zum Funktionsumfang?

TUXEDO Tomte Light bleibt bewusst minimalistisch.
Nicht enthalten sind:

• NVIDIA-/Hybrid-GPU-spezifische Konfigurationen
• Entfernen oder Bereinigen alter Kernel
• Treiber-Updates außerhalb der Fixpakete
• Ausführen von Shell-Skripten
• selektives Blockieren oder Entfernen einzelner Fixes
• ein umfangreiches CLI (bewusst minimal)

Wie installiere ich TUXEDO Tomte Light?

Die Pakete stehen bereits jetzt im GitLab bereit. Ab Anfang nächster Woche wird TUXEDO Tomte Light über die offiziellen TUXEDO Software-Repositories ausgeliefert.

Es werden jeweils die aktuellen Distributionen unterstützt (z. B. Fedora 43).
 

Tekkie-Ecke – unter der Haube von TUXEDO Tomte Light

Implementierung & Abhängigkeiten

• Implementiert in Python mit moderner Projektstruktur pyproject.toml, setzt auf eine aktuelle Python-Version und nutzt PyYAML für die Konfigurationsverarbeitung.
• Ein zentrales Logging-Setup trennt INFO/DEBUG nach STDOUT und WARN/ERROR/CRITICAL nach STDERR.

Hardware-Erkennung

• Hardwaredaten werden über lspci -n und lsusb mit Timeout gesammelt.
• Anschließend werden PCI- und USB-Geräte direkt aus /sys/bus/pci/devices und /sys/bus/usb/devices gelesen und zu normalisierten vendor:device-IDs im Hex-Format zusammengeführt.
• Zusätzlich wird die Anzahl der GPUs ermittelt, indem PCI-Geräte mit der passenden Klassenkennung gezählt werden.

Start-, Wiederhol- und Fehlerverhalten

• TUXEDO Tomte Light wird standardmäßig:

• 5–10 Minuten nach dem Systemstart ausgeführt,

• danach alle 12 Stunden erneut.

• Bei ungraceful exits – z. B. wenn:

• kein Internet verfügbar ist,

• der Paketmanager gesperrt ist,

• ein Timeout auftritt –
  → wird der Lauf bis zu zweimal automatisch wiederholt,
  → jeweils mit 30 Minuten Verzögerung.

So wird sichergestellt, dass Fix- und Boardpakete auch unter schwierigen Netzwerk- oder Paketmanagerbedingungen installiert werden können.

Regel-Engine & Konfigurationsschichten

• Die Konfiguration wird aus mehreren YAML-Schichten geladen, z. B.:
• base.yaml
• optional tuxedo-devices.yaml (geräteabhängig)
• optional tuxedo-os.yaml (OS-spezifisch)
• Welche Schichten aktiv sind, hängt davon ab, ob:
• das System als TUXEDO-Gerät erkannt wird (DMI-Strings),
• und/oder ein TUXEDO OS läuft /etc/os-release.
• Die YAML-Struktur beschreibt Bedingungen wie:
• PCI-ID-Listen
• USB-ID-Listen
• Mindestanzahl an GPUs GPU_COUNT_min
• Ein Validierungsschritt stellt sicher, dass die Konfiguration formal korrekt aufgebaut ist, bevor sie verwendet wird.

Match-Logik & Paketabbildung

• Aus den gesammelten Hardwaredaten werden alle relevanten Geräte-IDs mit regulären Ausdrücken gegen die Konfigurationsregeln gematcht (PCI/USB/GPU_COUNT).
• Das Ergebnis ist eine Menge abstrakter Paketnamen (Fix- oder Meta-Pakete), die noch nicht distributionsspezifisch sind.
• Eine Mapping-Tabelle package_mapper.yaml übersetzt diese Paketnamen – sofern nötig - abhängig von ID und ID_LIKE aus /etc/os-release auf konkrete Paketnamen der jeweiligen Distribution.
• Bereits als installiert markierte Pakete werden vor der Installation gefiltert.

Board-Erkennung & Board-Metapakete

• DMI-Informationen /sys/class/dmi/id/board_name und board_vendor werden eingelesen und mittels eines Filters in gültige Paketnamenform gebracht (nur zulässige Zeichen, normalisierte Schreibweise).
• Daraus werden Meta-Paketnamen wie tuxedo-board- und tuxedo-board-vendor- abgeleitet.
• Existierende Board-Metapakete werden gemeinsam mit den hardwarebasierten Fixpaketen installiert und so automatisch eingebunden, sobald sie bereitstehen.

Paketmanager-Abstraktion

• Eine abstrakte PackageManager-Klasse kapselt Aufrufe an das System und normalisiert Logging, Exitcodes und Ausgabe.
• Konkrete Implementierungen existieren für:
• apt-get (Debian/Ubuntu-Welt)
• dnf (Fedora)
• zypper (openSUSE)
• pacman (Arch)
• Der aktive Paketmanager wird automatisch anhand der vorhandenen Binaries ermittelt, mit definierter Priorität und expliziten Existenzchecks pro Paket (z. B. via apt-cache policy, rpm/dnf repoquery, zypper search).

Zustandsverwaltung

• Installationszustand wird unter /var/lib/tuxedo-tomte-light/state/installed verwaltet.
• Für jedes installierte Paket wird eine Flagdatei mit Zeitstempel angelegt, um Wiederholungen und unnötige Installationsversuche zu vermeiden.
• Über –reset lässt sich dieser Zustand gezielt zurücksetzen; mit –force werden Flags entfernt und der Ablauf direkt erneut gestartet.

In Summe ergibt sich eine kleine, klar abgegrenzte Engine, die:

• Hardware deterministisch erkennt
• Regeln aus YAML-Schichten auswertet
• Pakete distributionsspezifisch abbildet
• ausschließlich über die nativen Paketmanager arbeitet
• und ihren eigenen Zustand transparent nachverfolgbar speichert.

Frohen Nikolaus und viel Freude mit Tomte Light wünschen die TUXEDO Pinguine!