Toolbx

26. Dezember 2025 um 09:28

Beim Experimentieren mit KI-Sprachmodellen bin ich über das Projekt »Toolbx« gestolpert. Damit können Sie unkompliziert gekapselte Software-Umgebungen erzeugen und ausführen.

Toolbx hat große Ähnlichkeiten mit Container-Tools und nutzt deren Infrastruktur, unter Fedora die von Podman. Es gibt aber einen grundlegenden Unterschied zwischen Docker/Podman auf der einen und Toolbx auf der anderen Seite: Docker, Podman & Co. versuchen die ausgeführten Container sicherheitstechnisch möglichst gut vom Host-System zu isolieren. Genau das macht Toolbx nicht! Im Gegenteil, per Toolbx ausgeführte Programme können auf das Heimatverzeichnis des aktiven Benutzers sowie auf das /dev-Verzeichnis zugreifen, Wayland nutzen, Netzwerkschnittstellen bedienen, im Journal protokollieren, die GPU nutzen usw.

Toolbx wurde ursprünglich als Werkzeug zur Software-Installation in Distributionen auf der Basis von OSTree konzipiert (Fedora CoreOS, Siverblue etc.). Dieser Artikel soll als eine Art Crash-Kurs dienen, wobei ich mit explizit auf Fedora als Host-Betriebssystem beziehe. Grundwissen zu Podman/Docker setze ich voraus.

Mehr Details gibt die Projektdokumentation. Beachten Sie, dass die offizielle Bezeichnung des Projekts »Toolbx« ohne »o« in »box« lautet, auch wenn das zentrale Kommando toolbox heißt und wenn die damit erzeugten Umgebungen üblicherweise Toolboxes genannt werden.

Hello, Toolbx!

Das Kommando toolbox aus dem gleichnamigen Paket wird ohne sudo ausgeführt. In der Minimalvariante erzeugen Sie mit toolbox <name> eine neue Toolbox, die als Basis ein Image Ihrer Host-Distribution verwendet. Wenn Sie also wie ich in diesen Beispielen unter Fedora arbeiten, fragt toolbox beim ersten Aufruf, ob es die Fedora-Toolbox herunterladen soll:

toolbox create test1

  Image required to create Toolbx container.
  Download registry.fedoraproject.org/fedora-toolbox:43 (356.7MB)? [y/N]: y
  Created container: test1

Wenn Sie als Basis eine andere Distribution verwenden möchten, geben Sie den Distributionsnamen und die Versionsnummer in zwei Optionen an:

toolbox create --distro rhel --release 9.7 rhel97

Das Kommando toolbox list gibt einen Überblick, welche Images Sie heruntergeladen haben und welche Toolboxes (in der Podman/Docker-Nomenklatur: welche Container) Sie erzeugt haben:

toolbox list

  IMAGE ID      IMAGE NAME                                    CREATED
  f06fdd638830  registry.access.redhat.com/ubi9/toolbox:9.7   3 days ago
  b1cc6a02cef9  registry.fedoraproject.org/fedora-toolbox:43  About an hour ago

  CONTAINER ID  CONTAINER NAME     CREATED         STATUS   IMAGE NAME
  695e17331b4a  llama-vulkan-radv  2 days ago      exited   docker.io/kyuz0/amd-strix-halo-toolboxes:vulkan-radv
  dc8fd94977a0  rhel97             22 seconds ago  created  registry.access.redhat.com/ubi9/toolbox:9.7
  dd7d51c65852  test1              18 minutes ago  created  registry.fedoraproject.org/fedora-toolbox:43

Um eine Toolbox aktiv zu nutzen, aktivieren Sie diese mit toolbox enter. Damit starten Sie im Terminal eine neue Session. Sie erkennen nur am veränderten Prompt, dass Sie sich nun in einer anderen Umgebung befinden. Sie haben weiterhin vollen Zugriff auf Ihr Heimatverzeichnis; die restlichen Verzeichnisse stammen aber überwiegend von Toolbox-Container. Hinter den Kulissen setzt sich der in der Toolbox sichtbare Verzeichnisbaum aus einer vollkommen unübersichtlichen Ansammlung von Dateisystem-Mounts zusammen. findmnt liefert eine über 350 Zeilen lange Auflistung!

toolbox enter test1

[kofler@toolbx ~]$ cat /etc/os-release 

  NAME="Fedora Linux"
  VERSION="43 (Toolbx Container Image)"
  RELEASE_TYPE=stable
  ID=fedora
  VERSION_ID=43
  ...

[kofler@toolbx ~]$ findmnt | wc -l

  359

Innerhalb einer Fedora-Toolbox können Sie wie üblich mit rpm und dnf Pakete verwalten. Standardmäßig ist nur ein relativ kleines Subset an Paketen installiert.

[kofler@toolbx ~]$ rpm -qa | wc -l

  340

Innerhalb der Toolbox können Sie mit sudo administrative Aufgaben erledigen, z.B. sudo dnf install <pname>. Dabei ist kein Passwort erforderlich.

ps ax listet alle Prozesse auf, sowohl die der Toolbox als auch alle anderen des Hostsystems!

Mit exit oder Strg+D verlassen Sie die Toolbox. Sie können Sie später mit toolbox enter <name> wieder reaktivieren. Alle zuvor durchgeführten Änderungen gelten weiterhin. (Hinter den Kulissen verwendet das Toolbx-Projekt einen Podman-Container und speichert Toolbox-lokalen Änderungen in einem Overlay-Dateisystem.)

Bei ersten Experimenten mit Toolbx ist mitunter schwer nachzuvollziehen, welche Dateien/Einstellungen Toolbox-lokal sind und welche vom Host übernommen werden. Beispielsweise ist /etc/passwd eine Toolbox-lokale Datei. Allerdings wurden beim Erzeugen dieser Datei die Einstellungen Ihres lokalen Accounts von der Host-weiten Datei /etc/passwd übernommen. Wenn Sie also auf Host-Ebene Fish als Shell verwenden, ist /bin/fish auch in der Toolbox-lokalen passwd-Datei enthalten. Das ist insofern problematisch, als im Standard-Image für Fedora und RHEL zwar die Bash enthalten ist, nicht aber die Fish. In diesem Fall erscheint beim Start der Toolbox eine Fehlermeldung, die Bash wird als Fallback verwendet:

toolbox enter test1

  bash: Zeile 1: /bin/fish: Datei oder Verzeichnis nicht gefunden
  Error: command /bin/fish not found in container test1
  Using /bin/bash instead.

Es spricht aber natürlich nichts dagegen, die Fish zu installieren:

[kofler@toolbx ~]$ sudo dnf install fish

Auf Host-Ebene liefern die Kommandos podman ps -a und podman images sowohl herkömmliche Podman-Container und -Images als auch Toolboxes. Aus Podman-Sicht gibt es keinen Unterschied. Der Unterschied zwischen einem Podman-Container und einer Toolbox ergibt sich erst durch die Ausführung (bei Podman mit sehr strenger Isolierung zwischen Container und Host, bei Toolbox hingegen ohne diese Isolierung).

Eigene Toolboxes erzeugen

Eigene Toolboxes richten Sie ein wie eigene Podman-Images. Die Ausgangsbasis ist ein Containerfile, das die gleiche Syntax wie ein Dockerfile hat:

# Datei my-directory/Containerfile
FROM registry.fedoraproject.org/fedora-toolbox:43

# Add metadata labels
ARG NAME=my-toolbox
ARG VERSION=43
LABEL com.github.containers.toolbox="true" \
      name="$NAME" \
      version="$VERSION" \
      usage="This image is meant to be used with the toolbox(1) command" \
      summary="Custom Fedora Toolbx with joe and fish"

# Install your software
RUN dnf --assumeyes install \
    fish \
    joe

# Clean up
RUN dnf clean all

Mit podman build erzeugen Sie das entsprechende lokale Image:

cd my-directory

podman build --squash --tag localhost/my-dev-toolbox:43 .

Jetzt können Sie auf dieser Basis eine eigene Toolbox einrichten:

toolbox create --image localhost/my-toolbox:43 test2

toolbox enter test2

KI-Sprachmodelle mit Toolbx ausführen

Das Toolbx-Projekt bietet eine großartige Basis, um GPU-Bibliotheken und KI-Programme auszuprobieren, ohne die erforderlichen Bibliotheken auf Systemebene zu installieren. Eine ganze Sammlung von KI-Toolboxes zum Test diverser Software-Umgebungen für llama.cpp finden Sie auf GitHub, beispielsweise hier:

https://github.com/kyuz0/amd-strix-halo-toolboxes

toolbox create erzeugt eine Toolbox mit dem Namen llama-vulkan-radv auf Basis des Images vulkan-radv, das der Entwickler kyuz0 im Docker Hub hinterlegt hat. Das alleinstehende Kürzel -- trennt die toolbox-Optionen von denen für Podman/Docker. Die folgenden drei Optionen sind erforderlich, um der Toolbox direkten Zugriff auf das Device der GPU zu geben.

toolbox create llama-vulkan-radv \
  --image docker.io/kyuz0/amd-strix-halo-toolboxes:vulkan-radv \
  -- --device /dev/dri \
     --group-add video \
     --security-opt seccomp=unconfined

Mit toolbox enter starten Sie die Toolbox. Innerhalb der Toolbox steht das Kommando llama-cli zur Verfügung. In einem ersten Schritt können Sie testen, ob diese Bibliothek zur Ausführung von Sprachmodellen eine GPU findet.

toolbox enter llama-vulkan-radv

llama-cli --list-devices

  ggml_vulkan: Found 1 Vulkan devices:
  ggml_vulkan: 0 = Radeon 8060S Graphics (RADV GFX1151) (radv) | 
    uma: 1 | fp16: 1 | bf16: 0 | warp size: 64 | 
    shared memory: 65536 | int dot: 1 | matrix cores: KHR_coopmat
  Available devices:
    Vulkan0: Radeon 8060S Graphics (RADV GFX1151) 
    (107008 MiB, 99195 MiB free)

Wenn Sie auf Ihrem Rechner noch keine Sprachmodelle heruntergeladen haben, finden Sie geeignete Modelle unter https://huggingface.co. Ich habe stattdessen im folgenden Kommando ein Sprachmodell ausgeführt, das ich zuvor in LM Studio heruntergeladen haben. Wie gesagt: In der Toolbox haben Sie vollen Zugriff auf alle Dateien in Ihrem Home-Verzeichnis!

llama-server \
  -m  /home/kofler/.lmstudio/models/lmstudio-community/gpt-oss-20b-GGUF/gpt-oss-20b-MXFP4.gguf \
  -c 32000 -ngl 999 -fa 1 --no-mmap

Dabei gibt -c die maximale Kontextgröße an. -ngl bestimmt die Anzahl der Layer, die von der GPU verarbeitet werden sollen (alle). -fa 1 aktiviert Flash Attention. Das ist eine Grundvoraussetzung für eine effiziente Ausführung moderner Modelle. --no-mmap bewirkt, dass das ganze Modell zuerst in den Arbeitsspeicher geladen wird. (Die Alternative wären ein Memory-Mapping der Datei.) Der Server kann auf der Adresse localhost:8080 über eine Weboberfläche bedient werden.

Weboberfläche zu llama.cpp. Dieses Programm wird in einer Toolbox ausgeführt.

Anstatt erste Experimente in der Weboberfläche durchzuführen, können Sie mit dem folgenden Kommando einen einfachen Benchmarktest ausführen. Die pp-Ergebnisse beziehen sich auf das Prompt Processing, also die Verarbeitung des Prompts zu Input Token. tg bezeichnet die Token Generation, also die Produktion der Antwort.

llama-bench \
  -m /home/kofler/.lmstudio/.../gpt-oss-20b-MXFP4.gguf \
  -ngl 999 -fa 1

  model                       size  params ...  test   t/s
  gpt-oss 20B MXFP4 MoE  11.27 GiB   20.91     pp512  1219
  gpt-oss 20B MXFP4 MoE  11.27 GiB   20.91     tg128    78

Lese-Ansicht

Hello, Toolbx!

Eigene Toolboxes erzeugen

KI-Sprachmodelle mit Toolbx ausführen

Quellen/Links

Auswahl

Lieferung

Benchmark-Tests

BIOS

Stromverbrauch

Geräuschentwicklung

Fazit

Quellen/Links

Installation

COSMIC Desktop

Paketverwaltung

Boot-System

Fazit

Quellen/Links

Leseprobe

Fazit