Create, enter, and manage Distrobox containers for mutable package installation on Bluefin.
domain
sysadmin
tags
["distrobox","containers","packages","linux"]
version
2.0
Distrobox
Distrobox runs Linux distribution containers that integrate seamlessly with the host OS —
sharing the home directory, display server, audio, DBus, and hardware devices. Use it to
install RPM/DEB packages, run distribution-specific toolchains, or export apps/binaries to
the host without touching the immutable base image.
When to Use
Installing RPM/DEB packages not available as Flatpaks or Homebrew formulas
Running distribution-specific tools (dnf, apt, yum, pacman) without altering the host
Toolchains (Go, Rust, Python envs, Node versions) that need root-level package management
GUI apps that lack a Flatpak release or whose Flatpak is broken/outdated
NVIDIA-accelerated workloads that need full Linux library stacks (ML, CUDA)
Reproducible developer environments defined as code (distrobox-assemble)
When NOT to Use
GUI apps with a good Flatpak release — prefer flatpak install (better sandboxing, auto-updates)
CLI tools available as Homebrew formulas — prefer brew install (lighter weight, no container overhead)
One-off commands that don't need a persistent container — use podman run --rm
Anything requiring a real system daemon inside the container (use a VM instead)
Quick Start
# 1. Create a Fedora container (recommended on Bluefin)
distrobox create --name mybox --image registry.fedoraproject.org/fedora:latest
# 2. Enter and install packages
distrobox enter mybox
sudo dnf install git vim golang
# 3. Export an app so it appears in the GNOME app grid
distrobox-export --app code # GUI app
distrobox-export --bin /usr/bin/go --export-path ~/.local/bin # CLI binary# 4. Exit the containerexit# Other lifecycle commands
distrobox list # show all containers
distrobox stop mybox # stop a running container
distrobox rm mybox # delete a container (data in home is preserved)
distrobox-assemble lets you define containers as code in an INI file and recreate them
idempotently. Commit distrobox.ini to your dotfiles for reproducible environments.
distrobox.ini:
[fedora-dev]image=registry.fedoraproject.org/fedora:latest
pull=trueroot=falsereplace=falseinit=falseadditional_packages=git vim curl golang nodejs
[ubuntu-tools]image=docker.io/library/ubuntu:22.04pull=trueroot=falseadditional_packages=build-essential python3-pip
# Create all containers defined in the file
distrobox-assemble create --file distrobox.ini
# Destroy all containers defined in the file
distrobox-assemble rm --file distrobox.ini
# Dry-run to preview what would happen
distrobox-assemble create --file distrobox.ini --dry-run
Key INI options:
Option
Effect
image
OCI image reference
pull=true
Always pull the latest image before creating
replace=false
Don't destroy and recreate if container already exists
init=false
Skip running the init script (faster; set true for systemd-based images)
additional_packages
Space-separated list installed during first boot
home
Override the container home directory path
volume
Extra volume mounts (/host/path:/container/path)
pre_init_hook
Shell command run before package installation
post_init_hook
Shell command run after package installation
distrobox init — First-Boot Setup Scripts
When you need to run custom setup logic (dotfiles, config, tool downloads) the first time a
container is created, pass a script via --init-hooks or the init_hooks INI key.
distrobox-export --app <name> handles most cases, but sometimes the app name doesn't match
the .desktop file, or the app isn't installed to a standard location.
Use distrobox-generate-entry to create the entry manually.
# Find the .desktop file inside the container
find /usr/share/applications -name "*.desktop" | grep -i myapp
# Generate a .desktop entry pointing to this container
distrobox-generate-entry myapp --container mybox --export-label " (mybox)"# Remove a previously generated entry
distrobox-generate-entry myapp --container mybox --delete
distrobox-enter vs distrobox run
distrobox enter
distrobox run
Use case
Interactive shell session
Run a single command non-interactively
Allocates TTY
Yes
No (unless -- passes -t)
Shell
Login shell (reads .bashrc, etc.)
Direct exec, minimal environment
Exit code
Shell's exit code
Command's exit code (propagated cleanly)
Typical use
Development work, exploration
Scripting, CI one-shots, cron jobs
Run a single command non-interactively: distrobox run --name mybox -- go test ./...
Home Directory and Volumes
Default: Shared Home
By default, Distrobox bind-mounts the host's $HOME into the container at the same path —
files created in either environment are immediately visible in both.
Isolated Home: --home
Use --home to give a container its own private home directory (no host dotfiles):
Export a service running inside a container so the host systemd manages it.
# Inside the container: install and enable the service
distrobox enter mybox
sudo dnf install syncthing
systemctl --user enable syncthing.service
# Export to host
distrobox-export --service syncthing.service
exit# On the host
systemctl --user start syncthing.service
systemctl --user enable syncthing.service
The exported .service file lands in ~/.config/systemd/user/ and wraps the in-container
process transparently. To remove: distrobox-export --service syncthing.service --delete && systemctl --user daemon-reload
GPU Passthrough (NVIDIA Variant)
Users on bluefin-nvidia can pass the GPU into a container for CUDA workloads, ML
training, or GPU-accelerated rendering.
distrobox create \
--name nvidia-box \
--image registry.fedoraproject.org/fedora:latest \
--nvidia
distrobox enter nvidia-box
nvidia-smi # verify GPU is visible
nvcc --version # if CUDA toolkit installed
python3 -c "import torch; print(torch.cuda.is_available())"
Requirements:
Host must be on bluefin-nvidia (NVIDIA drivers pre-installed)
Container and host NVIDIA driver versions must match — Distrobox bind-mounts the host
driver stack; version mismatches cause failures
--nvidia also sets NVIDIA_VISIBLE_DEVICES and NVIDIA_DRIVER_CAPABILITIES
Ptyxis (default terminal on Bluefin) has first-class Distrobox support — all running
containers appear as selectable shell profiles in the sidebar. No CLI needed.
Click the + (new tab) dropdown → select a container name
Each tab shows which container (or host) it's running in
No configuration required — Ptyxis auto-discovers Distrobox containers
GNOME GUI for creating, starting, stopping, and deleting containers, and opening terminals
into them with one click. Changes are reflected in the CLI immediately.
distrobox-upgrade — Updating All Containers
distrobox-upgrade --all # upgrade all containers
distrobox-upgrade mybox ubuntu-tools # upgrade specific containers
distrobox-upgrade --all --pull # pull latest images first, then upgrade
Runs the appropriate package manager (dnf upgrade, apt upgrade, pacman -Syu, etc.)
inside each container non-interactively. Schedule with a systemd timer for automated maintenance.
Troubleshooting
Container Won't Start
distrobox list # check status
podman ps -a | grep mybox # Podman's view
podman logs mybox # inspect logs# Force-remove stuck container and recreate
podman stop mybox && podman rm mybox
distrobox create --name mybox --image registry.fedoraproject.org/fedora:latest