distrobox create -i archlinux -n abox -H ~/home-abox --additional-flags "--device=nvidia.com/gpu=all" && distrobox enter abox -- bash -c "sudo pacman -Sy --noconfirm git base-devel && git clone https://aur.archlinux.org/yay-bin.git /tmp/yay-bin && cd /tmp/yay-bin && makepkg -si --noconfirm && rm -rf /tmp/yay-bin"
Sunday, April 12, 2026
distrobox with nvidia through NVIDIA Container Toolkit
First setup NVIDIA Container Toolkit and docker support for it based on your host's distrubution. Then you can:
nixos: enable nvidia in distrobox container using Nvidia Container Toolkit
What worked for me on nixos with docker (check nixos wiki on Nvidia and Nvidia Container Toolkit) was:
Then in the distrobox container you can check if nvidia is detected, using for example glxinfo. It should show:
Put the following in nixos configuration file:
distrobox create -i archlinux -n archbox --additional-flags "--device=nvidia.com/gpu=all"
Then in the distrobox container you can check if nvidia is detected, using for example glxinfo. It should show:
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
server glx extensions:
Put the following in nixos configuration file:
hardware.nvidia-container-toolkit.enable = true;
virtualisation.docker.daemon.settings.features.cdi = true;
Saturday, April 11, 2026
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:
Then create the drop-in configuration file:
If you use LightDM instead, the steps are identical but with a different directory:
After creating the file, reload the systemd daemon so it picks up the change:
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.
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.
Fedora 43: Install latest foxitreader
Download latest version (FoxitReader.enu.setup.2.4.5.0727). Foxitreader is no longer maintained, so this is the oldest version.
Follow the prompts.
wget https://cdn01.foxitsoftware.com/pub/foxit/reader/desktop/linux/2.x/2.4/en_us/FoxitReader.enu.setup.2.4.5.0727.x64.run.tar.gz
tar xzvf FoxitReader*.tar.gz
chmod +x ./"FoxitReader.enu.setup.2.4.5.0727(rb70e8df).x64.run"
sudo ./"FoxitReader.enu.setup.2.4.5.0727(rb70e8df).x64.run"
Follow the prompts.
gentoo with xfce4: krusader does not start from distrobox
kf.i18n: KLocalizedString: Domain is not set for this string, translation will not work. Please see https://api.kde.org/frameworks/ki18n/html/prg_guide.html msgid: "No jobs" msgid_plural: "" msgctxt: ""
Authorization required, but no authorization protocol specified
10:26:41.584-warning qt.qpa.xcb unknown@0 # could not connect to display :0.0
10:26:41.584-warning qt.qpa.plugin unknown@0 # From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin.
10:26:41.584-info qt.qpa.plugin unknown@0 # Could not load the Qt platform plugin "xcb" in "" even though it was found.
10:26:41.584-fatal default unknown@0 # This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: linuxfb, wayland-brcm, wayland-egl, wayland, vkkhrdisplay, vnc, offscreen, xcb, minimalegl, eglfs, minimal.
install xhost in gentoo host:
sudo emerge x11-apps/xhost
and allow access to display:
xhost +
now can enter the fedora distrobox
Friday, April 10, 2026
bedrock with hijacked gentoo and xfce4: missing icons from strata in xfce4 application menu
sudo touch /usr/share/icons/hicolor
sudo gtk-update-icon-cache
based on: https://old.reddit.com/r/bedrocklinux/comments/llt5pp/buggy_icons_from_other_stratums_in_gnome/gnuo7tv/
Thursday, April 09, 2026
tigervnc with fluxbox example setup
/etc/tigervnc/vncserver-config-mandatory
session=startfluxbox
securitytypes=none
geometry=2000x1200
localhost
alwaysshared
Gentoo install app-arch/ rar - license
To avoid license inssues in future, you can just accept all licenses in /etc/portage/make.conf:
ACCEPT_LICENSE="*"
Monday, April 06, 2026
Subscribe to:
Posts (Atom)