KI-Chroot mit Ubuntu 24.04

Auf meinem Hauptsystem läuft Debian Testing, was für die meisten Anwendungen hervorragend funktioniert. Für meine KI-Anwendungen, wie etwa Stable Diffusion, benötige ich allerdings ROCm, um die GPU nutzen zu können. Obwohl ROCm offiziell nur für Ubuntu veröffentlicht wird, ließ es sich zunächst auch unter Debian betreiben. Anfangs verlief das Setup relativ stabil, doch schon bald zeigte sich ein erstes Problem: Vor jedem Start von Stable Diffusion mussten bestimmte Umgebungsvariablen manuell gesetzt werden, damit die GPU korrekt erkannt wurde. Das war zwar lästig, aber zunächst noch handhabbar.

Nach einigen Systemupdates verschärften sich die Abhängigkeitsprobleme jedoch so stark, dass sich das System nur noch aktualisieren ließ, wenn ROCm vollständig entfernt wurde. Eine weitere Nutzung von ROCm unter Debian war damit nicht mehr möglich, und GPU-beschleunigtes Arbeiten kam zum Erliegen. Spätestens an diesem Punkt fiel die Entscheidung, ROCm nicht länger direkt auf dem Hauptsystem zu betreiben, sondern stattdessen eine isolierte chroot-Umgebung dafür einzurichten.

Erschwerend kam hinzu, dass sich einige KI-Frameworks unter Debian gar nicht erst sinnvoll installieren ließen. Automatic1111, das ich ursprünglich für Stable Diffusion verwenden wollte, ließ sich auf meinem System überhaupt nicht zum Laufen bringen. Als kurzfristigen Workaround griff ich zunächst auf EasyDiffusion zurück, da dieses weniger strikt von bestimmten Systemabhängigkeiten abhing und sich vergleichsweise unkompliziert starten ließ. Langfristig stellte dies jedoch keine zufriedenstellende Lösung dar, da ich Automatic1111 nutzen wollte und nicht dauerhaft um funktionale Einschränkungen herumarbeiten wollte.

Die chroot wurde schließlich mit debootstrap erstellt, wobei ich mich für Ubuntu 24.04 als Basis entschied. Ausschlaggebend dafür war die offizielle Unterstützung von ROCm, die eine deutlich einfachere und stabilere Installation ermöglichte. Das Einrichten der chroot erfolgte unkompliziert über folgenden Befehl:

1

sudo debootstrap noble /srv/ubuntu http://archive.ubuntu.com/ubuntu/

Um die chroot bequem zu starten und zu verwalten, verwende ich schroot. Die Konfiguration von schroot liegt unter

1

/etc/schroot/chroot.d/

und besteht aus einer einfachen INI-ähnlichen Datei. Grob aufgebaut enthält die Config mindestens folgende Angaben:

1
2
3
4
5
6
7
8

[ubuntu]
description=KI-Chroot mit Ubuntu 24.04 und ROCm
type=directory
directory=/srv/ubuntu
users=thomas
root-users=thomas
groups=sbuild
preserve-environment=true

Nach der Einrichtung kann die chroot mit

1

schroot -c ubuntu

gestartet werden. Innerhalb dieser isolierten Umgebung lässt sich ROCm problemlos installieren.

Die Installation erfolgt über die folgenden Befehle:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

tee /etc/apt/sources.list.d/rocm.list << EOF
deb [arch=amd64 signed-by=/etc/apt/keyrings/rocm.gpg] https://repo.radeon.com/rocm/apt/7.1.1 noble main
EOF

tee /etc/apt/preferences.d/rocm-pin-600 << EOF
Package: *
Pin: release o=repo.radeon.com
Pin-Priority: 600
EOF

apt update
apt install rocm-core rocm-dev rocm-smi rocm-utils

Ich habe dabei bewusst nicht das komplette ROCm-Paket installiert, sondern nur die Komponenten, die für die GPU-Nutzung mit Stable Diffusion nötig sind. Dadurch bleibt die chroot schlank und stabil. Nach der Installation funktioniert die GPU direkt, und zusätzliche Anpassungen von Umgebungsvariablen sind nicht mehr notwendig.

Nachdem ROCm erfolgreich installiert war und die GPU korrekt erkannt wurde, richtete ich in der chroot die Python-Umgebung für KI-Anwendungen ein.

1
2

apt update
apt install python3 python3-venv python3-pip

Anschließend legte ich eine isolierte Python-Umgebung an, um die Pakete sauber getrennt vom System zu halten:

1
2

python3 -m venv ~/chroot/ai
source ~/chroot/ai/bin/activate

Innerhalb dieser virtuellen Umgebung wurde anschließend PyTorch für ROCm installiert. Dabei stieß ich auf ein weiteres Problem: Immer wieder brach die Installation ab, obwohl auf der NVMe noch genügend Speicherplatz frei war. Ursache war jedoch nicht der Festplattenspeicher, sondern der temporäre Speicher, den pip während der Installation verwendet. Standardmäßig nutzt pip das Verzeichnis /tmp, das auf vielen Systemen als RAM-gestütztes tmpfs eingerichtet ist. Bei großen Paketen wie PyTorch reicht dieser RAM oft nicht aus, um die temporären Dateien zu entpacken und zu bauen, selbst wenn auf der NVMe noch reichlich Platz vorhanden ist.

Die Lösung bestand darin, pip ein anderes temporäres Verzeichnis auf der Festplatte zuzuweisen, das ausreichend Speicher bot. Dazu setzte ich einfach die Umgebungsvariable TMPDIR auf ein geeignetes Verzeichnis und startete pip darüber:

1
2

mkdir /home/thomas/TMPDIR
TMPDIR=/home/thomas/TMPDIR pip install --pre torch torchvision --index-url https://download.pytorch.org/whl/nightly/rocm7.1

Am Ende wurde die Installation von ROCm und PyTorch mit einem Pythonscript überprüft.

1
2
3
4
5
6
7
8
9

import torch

if torch.cuda.is_available():
    print("ROCm GPU wird erkannt!")
    print("Anzahl verfügbarer GPUs:", torch.cuda.device_count())
    for i in range(torch.cuda.device_count()):
        print(f"GPU {i}: {torch.cuda.get_device_name(i)}")
else:
    print("Keine ROCm GPU gefunden.")

Dieses wurde als test_rocm.py gespeichert und in der Python-Umgebung ausgeführt.

1

python test_rocm.py

Damit ist die Python-Umgebung einsatzbereit und kann für KI-Anwendungen genutzt werden.

Weil KI-Modelle oft viel Arbeitsspeicher benötigen und mein System nur über 16 GB RAM verfügt, was für SDXL- und FLUX-Workflows nicht ausreicht, habe ich noch eine 32 GB große Swap-Datei angelegt. Das geht schnell und verhindert Speicherengpässe bei aufwändigen KI-Generierungen:

1
2
3
4

sudo fallocate -l 32G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Damit die Swap-Datei auch nach einem Neustart automatisch eingehängt wird, habe ich einen Eintrag in /etc/fstab vorgenommen:

1

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Seitdem laufen auch speicherintensive Anwendungen wie ComfyUI mit SDXL oder FLUX stabil, wenn auch etwas langsamer als mit mehr physischem RAM.

Aktuell laufen in der chroot unter anderem Stable Diffusion über Automatic1111 und SDXL bzw FLUX über ComfyUI sowie Text-Generation-WebUI mit einem 20 B GPT-OSS-Modell von OpenAI in 4 Bit-Quantisierung sowie einem 8 B Modell von DeepSeek.

Die chroot selber fasse ich nie wieder an, denn: „Never touch a running system“.

Bilder zum Projekt