horizon-client: invalid locale and no font don't work well with xfce4 black theme

env GTK_THEME=Adwaita LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 horizon-client

Gentoo and nvidia: open /dev/dri/card0: No such file or directory

Gentoo upgrade broke Xorg? It's probably your NVIDIA module.

After a Gentoo system upgrade that includes a new kernel, Xorg can fail to start with a cryptic error: "open /dev/dri/card0: No such file or directory". The display manager dies, XFCE never loads, and you're left staring at a TTY.

The cause is simple. The upgrade installed new kernel sources, but the /usr/src/linux symlink was left pointing at the old ones — or pointing nowhere useful. When nvidia-drivers tries to rebuild its kernel module against the new kernel, it can't find the sources and silently fails. No module, no /dev/dri/card0, no Xorg.

To fix it, first check which kernel you're running and which sources are available:
uname -r eselect kernel list
Then point the symlink at the matching sources: eselect kernel set 1
Finally, rebuild the NVIDIA kernel module: emerge @module-rebuild
Restart your display manager and everything should be back to normal. The lesson: after any Gentoo kernel upgrade, always verify your /usr/src/linux symlink and run emerge @module-rebuild before rebooting.

Distrobox: failed to create task for container: failed to create shim task: OCI runtime create failed: cannot stat /usr/lib64/libEGL_nvidia.so.580.159.03: No such file or directory failed to start containers: fbox

I have distrobox container, fbox, which was created using the following command:

distrobox create -i quay.io/fedora/fedora:44-n fbox -H ~/home-fbox --additional-flags "--device=nvidia.com/gpu=all" '
It was working for a while, and now, after I upgraded my gentoo host, I can't enter fbox. I get the error:


Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: cannot stat /usr/lib64/libEGL_nvidia.so.580.159.03: No such file or directory failed to start containers: fbox
The solution was to regenerate nvidia.yaml:

sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml

xpra on gentoo: cuda is required

/etc/portage/package.use/xpra:
x11-wm/xpra -video_cards_nvidia

tigervnc: vncserver@:1.service: Deactivated successfully just after start on gentoo

Tigervnc server starts and then stops immedietly. The solution was to go to /etc/X11/Sessions, and rename Xsession file:

cd /etc/X11/Sessions
mv ./Xsession Xsession_bkp
And restart the vncserver.

chroot: failed to run command ‘/bin/bash’: No such file or directory

You can specify different shell, e.g.: sudo chroot /mnt/nixos /bin/sh

gentoo: Extra packages for xfce4

sudo emerge -av xfce-extra/xfce4-whiskermenu-plugin xfce4-cpugraph-plugin xfce-extra/xfce4-notes-plugin x11-apps/xhost app-admin/system-config-printer xdg-desktop-portal-gtk xfce4-sensors-plugin

distrobox: Opening Images in Native GIMP from IrfanView Running Under Wine in Distrobox

I use IrfanView via Wine inside a Distrobox container and wanted its external editor feature to open images directly in native GIMP. IrfanView passes the image path in Windows format (Z:\home\home-folder\Pictures\photo.jpg), so a small Python script handles the conversion and launches GIMP. Sounds simple. It wasn't.

Two things needed fixing before GIMP would even start. First, GIMP's sandboxed image loader (glycin) uses bubblewrap, which cannot create user namespaces inside a container — fixed with GLYCIN_DISABLE_SANDBOX=1. Second, any process launched from the script died the moment the script exited, because Wine kills all child processes when its own child (the Python script) returns.

Even after solving those, GIMP crashed every time it tried to open a file, with a GTK3 assertion failure inside GtkFileChooserWidget. The same command worked perfectly from the shell. The environment variables were identical. The difference turned out to be invisible to env: Wine installs a seccomp filter on its processes, and that filter is inherited by every child process across fork and exec. No amount of environment tweaking or session detachment can clear an inherited seccomp filter. GTK's file chooser widget makes a syscall during initialisation that Wine's filter blocks, and GIMP crashes.

The fix is to launch GIMP as a transient systemd user service with systemd-run --user --no-block. A process started this way is owned by systemd, not Wine — clean process state, no inherited seccomp filter, completely outside Wine's process tree.

#!/usr/bin/python
import os, sys, subprocess

def convert_wine_path(p):
    return p.replace('\\', '/').replace('Z:', '')

env = os.environ.copy()
img_file = convert_wine_path(sys.argv[1]) if len(sys.argv) == 2 else None

cmd = [
    'systemd-run', '--user', '--no-block',
    '--setenv=GLYCIN_DISABLE_SANDBOX=1',
    f'--setenv=DISPLAY={env["DISPLAY"]}',
    f'--setenv=HOME={env["HOME"]}',
    f'--setenv=XDG_RUNTIME_DIR={env["XDG_RUNTIME_DIR"]}',
    '/usr/bin/gimp'
]
if img_file:
    cmd.append(img_file)

subprocess.run(cmd)


Save it somewhere on your Linux filesystem, point IrfanView's external editor to the Z: path equivalent, and it works. The same trick applies to any native Linux app you need to launch cleanly from within Wine.

gentoo: There was an error during CUPS operation: "No such file or directory".

This happend for me with gentoo, cups and hplip. Had to install filters:
emerge --ask net-print/cups-filters End then
systemctl restart cups

gentoo and distrobox: OCI runtime exec failed: exec failed: unable to start container process: error starting setns process: exec: already started

I have gentoo host, with systemd, nvidia and docker. When I want to create a distrobox image with systemd in the container, e.g.:
distrobox create --nvidia -i archlinux -n abox -H ~/home-abox --init --additional-packages "systemd"
I was getting: OCI runtime exec failed: exec failed: unable to start container process: error starting setns process: exec: already started
The solution was to use crun container runtime, instead of default runc. To do this

1. Install crun: emerge -av app-containers/crun
2. Create `/etc/docker/daemon.json` with the content: {
"runtimes": {
"crun": {
"path": "/usr/bin/crun"
}
},
"default-runtime": "crun"
}
3. Restart docker sudo systemctl restart docker

bedrock linux: share getnoo's /etc/portage with stratas

For example file managers install in strta, e.g. mc, yazi, will not be able to go /etc/portage of gentoo. To fix that, share portage folder in

Add portage to [global] in /bedrock/etc/bedrock.conf: etc = adjtime, crypttab, default/grub, fstab, group, group+, group-, group.OLD, group.org, gshadow, gshadow+, gshadow-, gshadow.OLD, gshadow.org, hostname, hosts, login.defs, machine-id, modprobe.d/blacklist.conf, passwd, passwd+, passwd-, passwd.OLD, passwd.org, rc.local, resolv.conf, resolvconf/run, shadow, shadow+, shadow-, shadow.OLD, shadow.org, sudoers, portage
Then sudo brl apply

gentoo: example make.use

# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /usr/share/portage/config/make.conf.example for a more
# detailed example.

COMMON_FLAGS="-O2 -pipe -march=native"
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
FCFLAGS="${COMMON_FLAGS}"
FFLAGS="${COMMON_FLAGS}"

# NOTE: This stage was built with the bindist USE flag enabled

# This sets the language of build output to English.
# Please keep this setting intact when reporting bugs.
LC_MESSAGES=C.UTF-8

RUSTFLAGS="${RUSTFLAGS} -C target-cpu=native"

MAKEOPTS="-j4 -l5"

USE="dist-kernel"

# Appending getbinpkg to the list of values within the FEATURES variable
FEATURES="${FEATURES} getbinpkg"
# Require signatures
FEATURES="${FEATURES} binpkg-request-signature"

ACCEPT_LICENSE="*"

EMERGE_DEFAULT_OPTS="--binpkg-respect-use=y"

gentoo: set --binpkg-respect-use in make.use

Add to make.use: EMERGE_DEFAULT_OPTS="--binpkg-respect-use=n

gnome-boxes from flatpak: file selection window does not show

I had that issue on gentoo running systemd with xfce4. Even though xdg-desktop-portal and xdg-desktop-portal-gtk portals were installed and running, gnome-boxes file selection window was not working. The solution was to set gtk portal by default:

create ~/.config/xdg-desktop-portal/portals.conf:

[preferred]
default=gtk
org.freedesktop.impl.portal.FileChooser=gtk


gentoo: mask the use of new nvidia drivers for legacy cards

Latest nvidia drivers (595.58.03) will not work with old GPUs, e.g. (GTX 960), giving error:
probe with driver nvidia failed
In this case you can mask the newest driver and force gentoo to use older one. You can do this as follows:
echo '>x11-drivers/nvidia-drivers-581' > /etc/portage/package.mask/nvidia-drivers then emerge -avtDUu @world

Distrobox with systemd: "save as" does not work in chromium and brave

If "save as" window does not work in chromium and brave executed in distrobox, this maybe because, container's systemd hijacked debus from the host. Thus you can disable it in the container and restart the container:
systemctl --user mask dbus.socket dbus-broker.service
systemctl --user stop dbus.socket dbus-broker.service
In my case I was using fedora 43 in the container, on gentoo host running systemd and xfce4 (x11). The XDG portal (xdg-desktop-portal-gtk) on host was installed and running.

bedrock linux: krusader in arch strata does not open files with "Open with" menu from strata

On Bedrock Linux (hijacked gentoo with xfce4) with a non-KDE host session, Krusader's (installed in the arch linux strata) "Open With" silently fails for apps in a guest stratum because KDE's KRun launcher depends on session services that are never started outside a KDE session. The fix is to override the affected .desktop files locally and prepend their Exec lines with strat:
cp /bedrock/strata/arch/usr/share/applications/appname.desktop ~/.local/share/applications/appname.desktop

sed -i 's|^Exec=|Exec=strat arch |' ~/.local/share/applications/appname.desktop

update-desktop-database ~/.local/share/applications/


The simble bash script to do it automatically (fix-strata-desktop.sh) is: #!/bin/bash

STRATA="arch"
STRATA_ROOT="/bedrock/strata/$STRATA"
SRC="$STRATA_ROOT/usr/share/applications"
SRC_CROSS="$STRATA_ROOT/bedrock/cross/applications"
DEST="$HOME/.local/share/applications"

# Icon search dirs within the stratum, in priority order
ICON_SEARCH_DIRS=(
"$STRATA_ROOT/usr/share/icons/hicolor"
"$STRATA_ROOT/usr/share/icons"
"$STRATA_ROOT/usr/share/pixmaps"
)
ICON_EXTENSIONS=("png" "svg" "xpm")
# Preferred sizes in descending order (hicolor subdirs)
ICON_SIZES=("256x256" "128x128" "96x96" "64x64" "48x48" "32x32" "scalable")

# Resolve an icon name to an absolute path inside the stratum.
# Returns the path on stdout, or nothing if not found.
resolve_icon() {
local icon_name="$1"

# Already an absolute path — verify it exists (possibly via stratum root)
if [[ "$icon_name" == /* ]]; then
[[ -f "$icon_name" ]] && echo "$icon_name" && return
[[ -f "$STRATA_ROOT$icon_name" ]] && echo "$STRATA_ROOT$icon_name" && return
return
fi

# Strip any accidental extension for a clean name-based search
local base_name="${icon_name%.*}"

# 1. Search hicolor theme with preferred sizes first
for size in "${ICON_SIZES[@]}"; do
for ext in "${ICON_EXTENSIONS[@]}"; do
local candidate="$STRATA_ROOT/usr/share/icons/hicolor/$size/apps/$base_name.$ext"
[[ -f "$candidate" ]] && echo "$candidate" && return
done
done

# 2. Check pixmaps directly (flat directory, no subdirs) — catches vscodium, cups, etc.
for ext in "${ICON_EXTENSIONS[@]}"; do
local candidate="$STRATA_ROOT/usr/share/pixmaps/$base_name.$ext"
[[ -f "$candidate" ]] && echo "$candidate" && return
done

# 3. Walk all icon theme dirs (any size/category subdir)
for icon_dir in "${ICON_SEARCH_DIRS[@]}"; do
for ext in "${ICON_EXTENSIONS[@]}"; do
# Direct file in dir (pixmaps style — already handled above, but kept for custom dirs)
local candidate="$icon_dir/$base_name.$ext"
[[ -f "$candidate" ]] && echo "$candidate" && return
# Subdir search (themes with size/category layout)
# Prefer largest size by sorting descending on the size component
while IFS= read -r found; do
echo "$found" && return
done < <(find "$icon_dir" -name "$base_name.$ext" 2>/dev/null \
| sort -t'/' -k1,1 -r | head -1)
done
done
}

mkdir -p "$DEST"

for src_file in "$SRC"/*.desktop "$SRC_CROSS"/*.desktop; do
# Skip broken symlinks or non-files
[[ ! -f "$src_file" ]] && echo "Skipping: $(basename "$src_file")" && continue

filename=$(basename "$src_file")
dest_file="$DEST/$filename"

# FIX 1: Remove existing file first so cp never hits a permission-denied
# on files previously written by root (e.g. from an earlier sudo run).
if [[ -e "$dest_file" && ! -w "$dest_file" ]]; then
echo "Warning: removing unwritable existing file: $dest_file"
rm -f "$dest_file" || { echo "Error: cannot remove $dest_file — skipping"; continue; }
fi

cp -- "$src_file" "$dest_file" || { echo "Error: cp failed for $filename"; continue; }

# Fix Exec= lines that don't already use strat
if ! grep -q "Exec=strat $STRATA" "$dest_file"; then
sed -i "s|^Exec=|Exec=strat $STRATA |" "$dest_file"
fi

# Fix Icon= lines — resolve to absolute path inside the stratum
icon_value=$(grep -m1 "^Icon=" "$dest_file" | cut -d'=' -f2-)
if [[ -n "$icon_value" ]]; then
resolved=$(resolve_icon "$icon_value")
if [[ -n "$resolved" ]]; then
# Escape any special characters for sed
escaped=$(printf '%s\n' "$resolved" | sed 's/[[\.*^$()+?{|]/\\&/g')
sed -i "s|^Icon=.*|Icon=$escaped|" "$dest_file"
echo "Processed: $filename (icon -> $resolved)"
else
echo "Processed: $filename (icon '$icon_value' not resolved — left as-is)"
fi
else
echo "Processed: $filename (no Icon= entry)"
fi
done

update-desktop-database "$DEST"
echo "Done."


gentoo with systemd: simplescan from flatpak does not open Export save file window

Have to make sure that xdg-desktop-portal-gtk portal on gentoo is installed and running (run a regular user, not root): systemctl --user status xdg-desktop-portal-gtk.service If it is not running enable it: systemctl --user enable --now xdg-desktop-portal-gtk.service

gentoo with systemd and docker: use Nvidia runtime in distrobox through Nvidia container oolkit

Install nvidia container toolbox: sudo emerge -av nvidia-container-toolkit restart docker service: sudo systemctl restart docker Create and setup /etc/cdi: mkdir -p /etc/cdi
nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml Check if its working: nvidia-ctk cdi list Configure docker to use NVIDIA runtime: sudo nvidia-ctk runtime configure --runtime=docker Restart docker service again: sudo systemctl restart docker Before creating distrobox container, lets just perfrom basic check if nvidia is avaiable in docker: docker run --rm --device=nvidia.com/gpu=all ubuntu nvidia-smi If this shows your Nvidia driver and info about your gpu, than it works.

Create distrobox that uses nvidia (fedora 43 as an example): distrobox create -i quay.io/fedora/fedora:43 -n fbox -H ~/home-fbox --additional-flags "--device=nvidia.com/gpu=all"
Enter the distrobox container, fbox, in this example, and test using nvidia-smi: sudo nvidia-smi This should also give info about your nvidia gpu and its driver.

If inside the distrobox container, nvidia is only avaiable for root user, you have to check what group number is nvidia on the host: stat -c "%g" /dev/nvidia0 This will show a number, e.g. 27.
Then in the distrobox container, fbox in this example, you have to edit /etc/group and:
1. add yourself (i.e. normal user) to video group 2. Change video group number to match the one on the host, e.g. 27. For example, /etc/group in fbox
video:x:27:your-user-name

Gentoo and SDDM and Ligthdm: Fixing Inactive Mouse at Display Manager Startup in Gentoo with systemd

If you use Gentoo Linux with systemd and a display manager like SDDM or LightDM, you may have run into an annoying issue where the mouse is completely unresponsive on the display manager's login screen after a reboot or cold start. The keyboard works fine, but the mouse does nothing. A second reboot usually fixes it. The problem does not appear on other distributions like NixOS, Fedora, or Ubuntu.

This is a race condition. Gentoo's minimal default configuration does not add unnecessary delays or dependencies to services, which means your display manager can start before the kernel input subsystem and udev have finished initializing the mouse device. Other distributions work around this implicitly through their own service configurations, but on Gentoo you have to handle it yourself.

The fix is to make the display manager wait for udev to finish settling before it starts. Systemd has a built-in service for exactly this purpose called systemd-udev-settle. It blocks until udev has finished processing all queued device events, which includes input devices like your mouse. You wire your display manager to it using a systemd drop-in file.

For SDDM, first create the drop-in directory: mkdir -p /etc/systemd/system/sddm.service.d/

Then create the drop-in configuration file: cat > /etc/systemd/system/sddm.service.d/wait-for-input.conf << 'EOF'
[Unit] After=systemd-udev-settle.service
Wants=systemd-udev-settle.service
EOF

If you use LightDM instead, the steps are identical but with a different directory: mkdir -p /etc/systemd/system/lightdm.service.d/
cat > /etc/systemd/system/lightdm.service.d/wait-for-input.conf << 'EOF'
[Unit] After=systemd-udev-settle.service
Wants=systemd-udev-settle.service
EOF

After creating the file, reload the systemd daemon so it picks up the change: systemctl daemon-reload

That is all. On the next reboot, systemd will start systemd-udev-settle before launching your display manager, and it will wait for all input devices to be fully registered before the login screen appears. The mouse will work on the very first try.

The reason this only affects Gentoo is that you compile and configure everything yourself. There is no distribution maintainer quietly patching service files or adding conservative boot ordering on your behalf. That level of control is what makes Gentoo great, but it also means issues like this surface in a way they simply would not on a more opinionated distribution.

If the problem persists after applying this fix, the next thing to investigate is whether your mouse and evdev drivers are compiled as kernel modules rather than built into the kernel, and whether INPUT_DEVICES is correctly set in your /etc/portage/make.conf.