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

xpra: More responsive remote connections

xpra start ssh://server/ --exit-with-children --start-child=terminator --encoding=jpeg --min-speed=100 --min-quality=0 --compress=1 --bandwidth-detection=yes --pixel-depth=16 --auto-refresh-delay=0 --video-scaling=2 --dpi=96
--min-speed — higher is faster. 100 is the maximum, meaning "always encode as fast as possible, never slow down for quality."

--min-quality — lower is faster. 30 means "allow aggressive quality reduction to save bandwidth." Setting it to 0 lets xpra reduce quality even further dynamically

Or run persistent server on the remote server

On the server: xpra start :100 --start-child=xfce4-terminal
On the client:
xpra attach ssh://curtin/:100 --encoding=jpeg --min-speed=100 --min-quality=0 --compress=1 --bandwidth-detection=yes --pixel-depth=16 --auto-refresh-delay=0 --video-scaling=2 --dpi=96

MATLAB on Arch Linux: java.lang.NullPointerException and MATLAB does not start

If MATLAB stopped launching after a recent Arch Linux system update and you see a java.lang.NullPointerException with a stack trace starting at DTSingleClientFrame.mainFrameCreated, likely reason could be a corrupted preferences folder.

You can confirm the issue by checking whether MATLAB works without the desktop:

matlab -nodesktop -nosplash

If that launches fine, the desktop preferences are to blame. The fix is simply to delete MATLAB's local preferences folder:
rm -rf ~/.matlab/R20*/
matlab

MATLAB will recreate the folder fresh on next launch and the desktop should start normally again. No reinstall needed.

picom: Sample confing in gentoo with xfce4 and nouveau dirver

Picom on Nouveau: Which Backend to Use If you're running the open-source nouveau NVIDIA driver and using the picom compositor, you've likely run into rendering glitches or crashes. The culprit is almost always the backend. Picom's GLX backend relies heavily on OpenGL, and nouveau's OpenGL support is incomplete. Stick to the xrender backend instead — it's slower, but stable. Create a config file at

~/.config/picom/picom.conf

with the following content:
backend = "xrender";

Vsync — disable, nouveau's support is unreliable
vsync = false;

Shadows
shadow = true;
shadow-radius = 7;
shadow-opacity = 0.75;
shadow-offset-x = -7;
shadow-offset-y = -7;

Fading
fading = true;
fade-in-step = 0.03;
fade-out-step = 0.03;

Opacity
inactive-opacity = 1.0;
frame-opacity = 1.0;
Then restart picom: pkill picom; picom -b
That's it. You trade some visual effects (blur requires GLX) for a stable desktop. If you ever switch to the proprietary NVIDIA driver, revisit the GLX backend for better performance.

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

arch: keditfiletype missing

yay kde-cli-tools