Distrobox ohne Magie: Warum Container plötzlich logisch wurden

LM Studio

OpenClaw?

Irgendein Tool, das in seiner Anleitung stillschweigend davon ausgeht, dass die Welt aus Ubuntu 24.04 besteht?

Perfekt.

Ab in die Distrobox.

Warum gerade Ubuntu 24.04 bei mir in der Box Sinn ergibt

Ich werde Ubuntu als Hauptsystem vermutlich nie ernsthaft lieben.

Das ist einfach nicht mein Zuhause.

Aber als Werkzeugraum?

Da ist Ubuntu plötzlich verdammt praktisch.

Viele Anleitungen im AI-/Python-/CUDA-/Linux-Tool-Bereich sind im Grunde heimliche Ubuntu-Anleitungen.

Da steht zwar manchmal „Linux“, aber gemeint ist oft:

„Ubuntu. Vielleicht Debian. Viel Glück beim Rest.“

Und genau dafür ist eine Ubuntu-Distrobox angenehm.

Mein Host kann NixOS oder sonst was sein.

Meine Tool-Umgebung kann trotzdem Ubuntu 24.04 sprechen.

Nicht, weil Ubuntu plötzlich mein Königreich wird.

Sondern weil der Werkzeughändler dort meistens weiß, in welchem Regal die Schrauben liegen.

Darum mag ich mein Schema:

ubu24-stm
ubu24-claw
ubu24-ai
ubu24-tools

Kurz, eindeutig, langweilig genug, um später noch zu verstehen, was ich da eigentlich gebaut habe.

Und das ist bei meinen Projekten leider schon fast ein Luxus.

Eine Ubuntu-Distrobox bauen

Eine einfache Ubuntu-24.04-Distrobox könnte zum Beispiel so aussehen:

distrobox create \
  --name ubu24-tools \
  --image docker.io/library/ubuntu:24.04

Dann rein:

distrobox enter ubu24-tools

Und drin erstmal Basiszeug installieren:

sudo apt update
sudo apt install -y \
  git curl wget ca-certificates \
  build-essential pkg-config \
  python3 python3-pip python3-venv pipx \
  nano micro \
  libgl1 libglib2.0-0

Das ist dann erstmal kein heiliger Gral.

Aber es ist ein sauberer Anfang.

Eine Box, in der ich Tools testen kann, ohne sofort mein Host-System mit „nur mal kurz“ zu segnen.

Und „nur mal kurz“ ist bei mir bekanntermaßen keine Zeitangabe.

Das ist eine Warnmeldung.

Wenn NVIDIA ins Spiel kommt

Jetzt kommt natürlich der Teil, bei dem Linux kurz die Nebelmaschine anschaltet:

NVIDIA.

Bei Distrobox gibt es offiziell den einfachen Weg mit:

distrobox create \
  --name ubuntu-nvidia \
  --image docker.io/library/ubuntu:24.04 \
  --nvidia

Das ist die hübsche Variante.

Die Variante, die sagt:

„Mach einfach diesen Schalter an, wird schon.“

Und auf manchen Systemen stimmt das auch.

Aber mein Linux-Leben wäre natürlich viel zu langweilig, wenn es immer bei „wird schon“ bleiben würde.

Gerade bei NixOS, Podman und NVIDIA kann es sinnvoller sein, nicht blind auf --nvidia zu vertrauen, sondern die GPU über zusätzliche Container-Flags durchzureichen.

Bei Podman mit NVIDIA CDI sieht das eher so aus:

distrobox create \
  --name ubu24-ai \
  --image docker.io/library/ubuntu:24.04 \
  --additional-flags "--device nvidia.com/gpu=all"

Das ist weniger hübsch.

Aber oft ehrlicher.

Statt:

„Distrobox, mach NVIDIA-Magie.“

sagt man eher:

„Podman, reich dieser Box bitte explizit alle NVIDIA-GPUs durch.“

Und ja, das sieht wieder aus wie ein Linux-Satz, den normale Menschen nicht freiwillig lesen würden.

Aber genau solche kleinen Details entscheiden am Ende darüber, ob nvidia-smi in der Box freundlich winkt oder dich anschweigt wie ein beleidigter Drucker.

Vorher prüfen: sieht Podman die GPU überhaupt?

Bevor ich eine AI-Distrobox baue und mich wundere, warum nichts geht, sollte ich erstmal prüfen, ob der Host die GPU sauber sieht.

Auf dem Host:

nvidia-smi

Wenn das schon nicht geht, braucht man in der Box gar nicht erst anfangen zu beten.

Dann ist nicht Distrobox schuld.

Dann steht der Keller unter Wasser, bevor man überhaupt Werkzeug reingetragen hat.

Wenn NVIDIA CDI genutzt wird, ist außerdem sowas interessant:

nvidia-ctk cdi list

Da sollte dann im Idealfall etwas auftauchen wie:

nvidia.com/gpu=0
nvidia.com/gpu=all

Und dann in der Box:

distrobox enter ubu24-ai
nvidia-smi

Wenn dort die GPU auftaucht, ist das schon mal ein kleiner Sieg.

Kein Weltfrieden.

Aber ein Sieg.

Gerade bei NVIDIA nimmt man, was man kriegt.

Meine AI-Box wäre ungefähr so

Für eine Ubuntu-24.04-Box mit AI-/Tool-Fokus würde ich grob so denken:

distrobox create \
  --name ubu24-stm \
  --image docker.io/library/ubuntu:24.04 \
  --init \
  --home ~/Distrobox/ubu24-stm \
  --additional-flags "--device nvidia.com/gpu=all" \
  --additional-packages "systemd libpam-systemd pipewire-audio-client-libraries"

Danach rein:

distrobox enter ubu24-stm

Dann prüfen:

echo $HOME
nvidia-smi
ps -p 1 -o comm=

Und dann Basiszeug:

sudo apt update
sudo apt install -y \
  git curl wget ca-certificates \
  build-essential pkg-config \
  python3-full python3-pip python3-venv pipx \
  libgl1 libglib2.0-0 \
  fuse libfuse2 \
  nano micro

Das ist natürlich kein universeller göttlicher Befehl, der auf jedem System perfekt ist.

Das ist eher mein pragmatischer Startpunkt.

Eine Box für Dinge wie Stability Matrix, LM Studio, OpenWebUII oder andere Tools, die ich nicht direkt in mein Hauptsystem gießen will wie Frittieröl in eine Tastatur.

Warum nicht einfach alles in NixOS?

Gerade bei NixOS könnte man natürlich sagen:

„Mach es doch richtig deklarativ.“

Ja.

Kann man.

Sollte man bei wichtigen Sachen vielleicht auch.

Aber nicht alles, was ich teste, verdient sofort einen Platz in meiner Systemkonfiguration.

Manche Dinge sind Experimente.

Manche Dinge sind Projektwerkzeug.

Manche Dinge sind:

„Ich weiß noch nicht, ob das genial oder kompletter Unsinn ist.“

Und genau dafür will ich nicht jedes Mal meine NixOS-Config anfassen, rebuilden, committen und so tun, als wäre diese Entscheidung jetzt Teil meiner digitalen Identität.

Distrobox erlaubt mir, unsauber zu testen, ohne mein sauberes Systemkonzept direkt zu verraten.

Das klingt widersprüchlich.

Ist aber ziemlich gesund… So rede ich mir das jedenfalls immer ein.

Flatpak, Distrobox und Host: wer macht was?

In meinem Kopf teilt sich das inzwischen ungefähr so auf:

• Host-System: Fundament, Desktop, Treiber, Bootloader, Shell, wichtige Basistools.
• Flatpak: normale Desktop-Apps, die sauber getrennt laufen dürfen.
• Distrobox: Entwicklungs-, AI-, Python-, CLI- und Spezialkram.
• Git/Codeberg: Gedächtnis und Sicherheitsnetz für Konfigurationen.

Das ist keine perfekte Architektur aus einem Enterprise-Handbuch.

Das ist eher:

„Wie verhindere ich, dass mein Spieltrieb mein Hauptsystem mit einem Stuhl bewirft?“

Und dafür funktioniert diese Trennung ziemlich gut.

Distrobox reduziert Reue

Der größte Vorteil ist für mich nicht einmal technisch.

Er ist psychologisch.

Wenn ich weiß, dass ein Experiment in einer Box lebt, teste ich entspannter.

Ich kann etwas kaputtmachen, ohne direkt den Host in die Notaufnahme zu schieben.

Wenn die Box irgendwann komplett aussieht wie ein Paketfriedhof mit Python-Geruch, dann ist das nicht tragisch.

distrobox rm ubu24-test

Weg damit.

Keine Trauerfeier.

Keine Bootloader-Seelsorge.

Keine nächtliche Forensik.

Einfach löschen und neu bauen.

Das ist für jemanden wie mich extrem wertvoll.

Weil ich gerne teste.

Aber mein Hauptsystem inzwischen nicht mehr jedes Experiment als Mitbewohner akzeptieren soll.

Wo Distrobox nicht die Lösung ist

Natürlich ist Distrobox kein Thermomix.

Es gibt Dinge, für die eine Box einfach nicht der richtige Ort ist.

• Kernel-Treiber
• Bootloader
• echte Host-Systemdienste
• Low-Level-GPU-Probleme
• Desktop-Compositor-Tests
• alles, was wirklich das System selbst verändern muss

Wenn ich Hyprland als komplette Session testen will, ist eine echte Installation oder VM meistens sinnvoller.

Wenn ich Bootloader operiere, hilft mir keine Ubuntu-Box.

Wenn NVIDIA auf dem Host kaputt ist, wird die Box auch nicht plötzlich eine Wunderheilung durchführen.

Distrobox ist kein Ersatz für Verständnis.

Distrobox ist eher ein Ort, an dem man Verständnis gewinnen kann, ohne direkt das Wohnzimmer anzuzünden.

Der eigentliche Aha-Moment

Mein Aha-Moment war also nicht:

„Wow, ich kann Ubuntu in einem Container starten.“

Sondern eher:

„Ich kann mir passende Werkzeugräume bauen, ohne mein Hauptsystem zu verbiegen.“

Das ist der Unterschied.

Eine Distrobox ist für mich keine zweite Heimat.

Sie ist eine Werkstatt.

Eine Quarantänezone.

Ein kleiner Werkzeugkeller.

Der Ort, an dem ich Dinge ausprobieren darf, die im Hauptsystem noch nichts verloren haben.

Und genau deshalb passt Distrobox so gut zu meinem Setup.

Ich kann ein NixOS als sauberes Zuhause bauen.

Ich kann CachyOS als vertrauten Arch-Außenposten behalten.

Und ich kann mir daneben Ubuntu-Boxen für AI-Kram, Tools und Experimente hinstellen.

Das ist nicht magisch.

Aber es ist praktisch.

Und manchmal ist praktisch viel besser als magisch.

Mein Fazit

Distrobox wurde für mich erst dann logisch, als ich aufgehört habe, es wie eine VM zu betrachten.

Es ist kein kleines Zweit-Linux zum Wegsperren.

Es ist ein Werkzeugraum neben dem Hauptsystem.

Nah genug, um wirklich damit zu arbeiten.

Weit genug weg, damit Experimente nicht sofort die Küche verwüsten.

Für jemanden wie mich, der einerseits ein sauberes, reproduzierbares System will und andererseits regelmäßig denkt:

„Ich teste nur kurz dieses eine GitHub-Projekt.“

ist das ziemlich perfekt.

Distrobox erlaubt mir, chaotisch zu bleiben, ohne mein Fundament ständig zu gefährden.

Und ganz ehrlich?

Das ist vermutlich genau die Art Kompromiss, die mein Linux-Leben gebraucht hat.