distrobox: export Notepad++ installed thorugh wine

distrobox-export --app Notepad++

void linux with docker: distrobox hangs when a container with --init and systemd is created.

Distrobox lets you run any Linux distribution as a container and integrate it into your host system. But if your host is Void Linux, getting a systemd-based box like Arch to boot correctly takes a bit of extra work.

The problem

Void uses runit as its init system, not systemd. When you create a distrobox with --init and ask for a systemd container, it will hang forever printing:

waiting for systemd to come up...
waiting for systemd to come up...
waiting for systemd to come up...

Even after fixing the cgroup setup (which also requires attention on a non-systemd host), systemd inside the container will fail on several units that try to mount kernel filesystems — things like binfmt_misc, hugepages, and sys-kernel-debug. These units make no sense inside a container and will block the boot sequence.

The fix

The solution is to mask those units at creation time, before systemd ever tries to start them. The --init-hooks flag runs a shell command during container setup, so we can pre-create the /dev/null symlinks that systemctl mask would normally create:

distrobox create -i archlinux -n abox -H ~/home-abox --init --additional-packages "systemd" --additional-flags "--privileged" --init-hooks "mkdir -p /etc/systemd/system && for u in proc-sys-fs-binfmt_misc.automount proc-sys-fs-binfmt_misc.mount sys-kernel-debug.mount sys-kernel-tracing.mount dev-hugepages.mount systemd-firstboot.service systemd-udevd.service; do ln -sf /dev/null /etc/systemd/system/\$u; done"

The --privileged flag gives systemd the capabilities it needs to manage its own cgroup namespace. The hook symlinks all the container-hostile units to /dev/null, which is exactly what masking does — just without needing systemctl to be running yet.

Why symlinks instead of systemctl? At hook execution time systemd hasn't started yet, so systemctl mask may not work reliably. Writing symlinks directly achieves the same result and works unconditionally.

Result

After running this command, distrobox enter abox will boot straight through into a fully working Arch Linux shell with a live systemd instance — on a Void Linux host running runit.

Posted March 2026

Void Linux: "/" is not a shared mount, this could cause issues or missing mounts with rootless containers

When running distrobox with podman:
"/" is not a shared mount, this could cause issues or missing mounts with rootless containers Just add mount --make-rshared / to your /etc/rc.local

Void Linux, podman and distrobox: unable to apply cgroup configuration

Error: unable to start container "0a58490ca8d4b9cf464483b8a776e53616ebfc60cc89aa25e60b0d910d907eb2": runc: runc create failed: unable to start container process: unable to apply cgroup configuration: rootless needs no limits + no cgrouppath when no permission is granted for cgroups: mkdir /sys/fs/cgroup/0a58490ca8d4b9cf464483b8a776e53616ebfc60cc89aa25e60b0d910d907eb2: permission denied: OCI permission denied
Create ~/.config/containers/containers.conf: [containers]
cgroupns = "host"


[engine]
cgroup_manager = "cgroupfs"
runtime = "crun"

sudo xbps-install -S crun

Remove the container, and install it again, e.g.: distrobox stop abox
distrobox rm abox
podman system reset
distrobox create -i archlinux -n abox -H ~/home-abox
distrobox-enter abox


Void Linux: podman and distrobox: short-name "archlinux" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.con

Error: short-name "archlinux" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"
Edit: /etc/containers/registries.conf and add:

unqualified-search-registries = ["docker.io"]

Fix: Firefox in Distrobox "Show in Folder" Opens the Wrong App on Linux

In Distrobox, install thunar if using xfce4 and add inode/directory=thunar.desktop into ~/.config/mimeapps.list: [Default Applications]
inode/directory=thunar.desktop

Start libreoffice in dark theme from distrobox on nix os through .desktop file

On Host, after exporting the libreoffice from distrobox, edit e.g. ~/.local/share/applications/abox-libreoffice-calc.desktop and add "env GTK_THEME=Adwaita:dark": Exec=env GTK_THEME=Adwaita:dark /run/current-system/sw/bin/distrobox-enter -n abox -- libreoffice --writer %U

flatpak: Kdenlive error: Could not initialize GLX

Could not initialize GLX Have to **update flatpak** as probably nvidia drivers in flatpaks are much different than on the host.

NixOS: Libreoffice in distrobox does not use Adwaita dark theme

GTK_THEME=Adwaita:dark libreoffic
or set in fish config:
set -x GTK_THEME Adwaita:dark

NixOS: Firefox in distrobox does not use Adwiata theme (no hand mouse cursor)

NixOS injects its Nix store paths into XCURSOR_PATH so the host system finds cursors in /nix/store/..., and distrobox inherits that variable. Inside the Arch container those paths don't exist, so libxcursor found nothing and silently fell back to the default arrow for every cursor change.
vim .config/fish/config.fish
set -e XCURSOR_PATH
set -x XCURSOR_PATH /usr/share/icons ~/.icons


When creating launcher for firefox in xfce4, have to reset `XCURSOR_PATH`:
/run/current-system/sw/bin/distrobox-enter -n abox -- bash -c 'XCURSOR_PATH=/usr/share/icons /usr/lib/firefox/firefox %u '