From Docker to bare-metal: running diffusion models on NVIDIA RTX 50 series (Blackwell) on Arch Linux
Back to blog

From Docker to bare-metal: running diffusion models on NVIDIA RTX 50 series (Blackwell) on Arch Linux

Updated 9/20/2026 · Published 9/18/2026 · 3 min · Artificial Intelligence

Anyone running generative AI locally knows that initial expectations rarely survive the first encounter with freshly released hardware. Recently, I set up a new laptop equipped with an NVIDIA GeForce RTX 5050 (8GB VRAM) running CachyOS (a performance-focused Arch Linux distribution).

The plan was straightforward: spin up a ComfyUI stack in a Docker Compose container, connect it to my pipeline, and run SDXL models (Juggernaut XL and Pony Diffusion). What seemed like a routine 15-minute setup quickly turned into an extensive troubleshooting session covering Docker volume mappings, CUDA support for the newly released Blackwell architecture, and dynamic system libraries.

Below is the complete troubleshooting breakdown, log analyses, and the working bare-metal path.


1. Initial hurdle: the empty /opt/storage directory and Docker mounts#

When starting the ComfyUI container using the AI-Dock base image (ghcr.io/ai-dock/comfyui:latest-cuda), the WebUI failed to index any model checkpoints, leaving the Load Checkpoint node stuck on undefined.

Inspect the container via the terminal:

docker exec -it comfyui ls -la /opt/storage/stable_diffusion/models/ckpt/
total 0
drwxrwsr-x 1 root ai-dock   0 Sep 26 2024 .
drwxrwsr-x 1 root ai-dock 182 Sep 26 2024 ..
-rw-rw-r-- 1 root ai-dock   0 Sep 26 2024 .gitkeep

Diagnosis#

The /opt/storage folder was an isolated filesystem directory inside the container and did not inherit the mounted /workspace volume. Attempting to remove the folder to create a symlink failed due to the hidden .gitkeep file:

docker exec -it comfyui rmdir /opt/storage/stable_diffusion/models/ckpt
rmdir: failed to remove '/opt/storage/stable_diffusion/models/ckpt': Directory not empty

I forcibly removed the directory and recreated the link pointing to the mounted data:

docker exec -it comfyui rm -rf /opt/storage/stable_diffusion/models/ckpt
docker exec -it comfyui ln -s /workspace/stable_diffusion/models/ckpt /opt/storage/stable_diffusion/models/ckpt

The WebUI still showed undefined on reload, revealing that the application binary looked for checkpoints directly in /opt/ComfyUI/models/checkpoints. In AI-Dock containers, inspect whether /opt/ComfyUI/models/checkpoints is already a symlink pointing to /opt/storage/... via docker exec comfyui ls -la /opt/ComfyUI/models/.

To create a clean, persistent mount surviving container recreations (docker compose down), I configured an explicit bind mount in docker-compose.yml:

services:
  comfyui:
    image: ghcr.io/ai-dock/comfyui:latest-cuda
    container_name: comfyui
    ports:
      - "8188:8188"
    volumes:
      - ./comfyui:/workspace
      - ./comfyui/stable_diffusion/models/ckpt:/opt/ComfyUI/models/checkpoints
    environment:
      - WEB_ENABLE_AUTH=false
      - NVIDIA_VISIBLE_DEVICES=all
      - PYTORCH_CUDA_ALLOC_CONF=expandable_segments:true
      - TORCH_CUDA_ARCH_LIST=12.0+PTX
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    restart: always

2. Hardware roadblock: CUDA error: no kernel image is available for execution#

With models properly indexed, clicking Queue Prompt immediately triggered a failure in the CLIPTextEncode node:

CUDA error: no kernel image is available for execution on the device
CUDA kernel errors might be asynchronously reported at some other API call.

Diagnosing the Blackwell architecture#

The RTX 5050 is built on the NVIDIA Blackwell architecture (Compute Capability 12.0).

Pre-packaged Docker images are compiled against PyTorch builds using CUDA 12.1 or 12.4 from before the RTX 50 series launch. Because those legacy binaries did not include binary CUDA kernels for Blackwell, PyTorch threw fatal exceptions the moment tensors reached the GPU.

Updating PyTorch inside the container ran into conflicting internal virtual environments. The cleanest path was to move from Docker to bare-metal, utilizing updated Arch/CachyOS system packages.


3. Bare-metal attempt and the Python 3.14 mismatch#

Cloning SD-WebUI-Forge to run natively via webui.sh:

git clone https://github.com/lllyasviel/stable-diffusion-webui-forge.git ~/ai-tools/stable-diffusion-webui-forge
cd ~/ai-tools/stable-diffusion-webui-forge
./webui.sh

Failed during virtualenv creation:

This program is tested with 3.10.6 Python, but you have 3.14.6.
ERROR: Could not find a version that satisfies the requirement torch==2.3.1
ERROR: No matching distribution found for torch==2.3.1

CachyOS ships bleeding-edge system packages, running Python 3.14. Legacy Stable Diffusion scripts pin older PyTorch releases (like 2.3.1) that have no prebuilt wheels available for newer Python versions.


4. The stabilitymatrix path: resolving libcrypt.so.1 and uv#

To manage isolated Python runtimes cleanly, I deployed StabilityMatrix.

During initialization, the runtime threw a missing dynamic library exception:

System.DllNotFoundException: Could not load libpython3.10.so: libcrypt.so.1: cannot open shared object file: No such file or directory

Resolving host dependencies on Arch / CachyOS#

Modern Arch Linux replaced libcrypt with libxcrypt. Portable apps depending on older Python 3.10 runtimes require the backward-compatibility package:

# 1. Install legacy compatibility library
sudo pacman -S libxcrypt-compat

# 2. Install the native 'uv' package manager
sudo pacman -S uv

With these two system packages in place, StabilityMatrix successfully initialized its isolated runtimes and compiled PyTorch with full GPU acceleration on the Blackwell architecture.


Practical takeaways for running AI on new GPUs#

  1. Verify internal Docker folder structures: Pre-built AI containers frequently use non-standard internal directories. Explicit bind mounts in Docker Compose pointing directly to the application path avoid broken symlinks.
  2. Brand-new GPUs require recent CUDA toolkits: New architectures (such as the RTX 50 series) require PyTorch 2.7+ with CUDA 12.8 wheels (the first toolkit providing native sm_120 kernels for the RTX 50 series); older builds on CUDA 12.4 or 12.6 lack these kernels and fail during tensor execution.
  3. Rolling-release distros benefit from compatibility packages: On Arch Linux and CachyOS, installing libxcrypt-compat and leveraging tools like uv and StabilityMatrix resolves Python version mismatches cleanly.

Conclusion#

In this post, I shared the complete journey — from Docker bind mount troubleshooting to an isolated runtime in StabilityMatrix. The combination that ultimately unlocked the RTX 5050 was straightforward: essential host packages (libxcrypt-compat, uv) paired with an isolated Python environment managed by StabilityMatrix, avoiding outdated container images and system Python conflicts alike.

Was this article helpful?

Leave a quick reaction to help prioritize future technical guides:

CC BY-NC

This post is licensed under CC BY-NC.

Comments

Join the discussion below.

0 comments