Linux

Install tool:

sudo apt install xclip

Perform the copy:

cat filename.base64 | xclip -rmlastnl -selection clipboard

On installation, the Citrix Workspace installer will ask for libwebkit2gtk-4.0-37. However, in the latest Debian, libwebkit2gtk-4.1-0 is installed. That package brings in many other packages so there is no practical way to install an earlier version.

The solution to this give the older Debian Bookworm a try where the package is available for installation.

> apt-cache search libwebkit2gtk
libwebkit2gtk-4.0-37 - Web content engine library for GTK
libwebkit2gtk-4.0-dev - Web content engine library for GTK - development files
libwebkit2gtk-4.0-doc - Web content engine library for GTK - documentation
libwebkit2gtk-4.1-0 - Web content engine library for GTK
libwebkit2gtk-4.1-dev - Web content engine library for GTK - development files

To prep for Citrix installation, install the following:

# apt install libwebkit2gtk-4.0-37 libcurl4 libspeexdsp1

APT based distributions like Debian can be containerized with a tool called debootstrap. It is part of the image build process of lxc-create. It is also referenced in Docker Base Images for building an image from scratch.

When looking at the build scripts included in the package installation, repositories for the following distributions can be found in /usr/share/debootstrap/scripts:

• debian - universal operating system
• trisquel - a distribution of the GNU operating system, with the kernel GNU Linux-libre
• ubuntu - modern enterprise open source
• pardus - Turkish
• kali - open-source, Debian-based Linux distribution geared towards various information security tasks, such as Penetration Testing, Security Research, Computer Forensics and Reverse Engineering
• elxr - Enterprise-Grade Linux for Edge-to-Cloud Deployments
• pureos - fully-convergent, user friendly, secure and freedom respecting OS for your daily usage

The wiki shows a simple two liner to get the basics of the distribution in place (as root):

mkdir trixie-chroot
debootstrap stable trixie-chroot http://deb.debian.org/debian/

Enter the chroot and note new root:

root@test:~# pwd
/root
root@test:~# chroot trixie/
root@test:/# pwd
/
root@test:/# exit
exit
root@test:~# pwd
/root

After the debootstrap, create the base for docker, and give it a try:

tar -C trixie-chroot -c . | docker import - trixie
docker run trixie cat /etc/debian_version
docker run --rm -i -t trixie /bin/bash

Although debootstrap can be used to build an image for a version subsequent, it is generally recommended to use debootstrap from at least the desired version to ensure it has the proper updates and dependencies.

Command line to summarize the referenced repositories:

grep -h default_mirror /usr/share/debootstrap/scripts/* \
  | sed 's/default_mirror//' \
  | sed 's/[ \t]//g' \
  | sort \
  | uniq

In the Nanog email list, the following was posted as a summary of current tooling use for network management in Debian:

Linux has a bunch of different possible ways to administer all of this stuff.

• The most comprehensive CLI mechanism is iproute2 (the “ip” command and some related constructs).
• The most comprehensive and capable persistent configuration database mechanism is systemd-networkd.

Other persistent mechanisms include:

• Netplan (YAML based configurations that now days mostly get parsed into systemd-networkd files and then executed).
• Debian Traditional (the /etc/network/interfaces file and/or interfaces.d directory, ifup/ifdown/etc.). Lacks many features, but most can be worked around with iproute2 shell commands added to triggers in the file.
• Debian Traditional can be supplemented with ifupdown2 - ifupdown replacement from Cumulus Networks
• NetworkManager (semi-capable, but any capabilities it lacks are just hard to cope with).

My strong recommendation is take the time to learn systemd-networkd and use it. It’s a bit of a pain and some of the syntax can be arcane and frustrating. It’s also annoying the way it dithers the configuration for a given interface across a multitude of files in some cases. However, when I think the obvious corner cases through and consider the alternatives, I usually find myself realizing that they’ve probably made as good a choice as any for what needs to be done.

Overall, it’s a pretty comprehensive interface and provides good logs for troubleshooting in most circumstances.

When creating a Debian testing/forky LXC container on a Debian trixie machine, the following error may be encountered in the output:

I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on http://deb.debian.org/debian...
E: Couldn't find these debs: isc-dhcp-client
Failed to download the rootfs, aborting.
Failed to download 'debian base'
failed to install debian

This is a result of bug #1125011 in the Debian bug tracker.

There are several possible solutions:

• Manually apply the patches supplied by the Debian LXC team
• Probably might be solved by running lxc-create on a testing/forky machine, where the solution may have already been applied - I have not confirmed this
• Or it may work on a sid machine

After following my own instructions for building my own LXC container template for ProxMox using the SID release, when the container started, the ProxMox logs would fill up with errors along the lines of:

apparmor="DENIED" operation="mount" class="mount" info="failed flags match" error=-13 name="/run/credentials/systemd-journald.service/" flags="rw, move"

My Trixie template did not seem to offer up these types of errors. LXC containers were created with the 'Unpriviledged Container" setting to 1|yes.

Instead of going the last resort brute force and ignorance route of using the following configuration (see Fixing net.ipv4.ip_unprivileged_port_start and AppArmor Docker Errors in a Proxmox LXC for some background):

lxc.apparmor.profile: unconfined
features: keyctl=1,nesting=1

I took a more nuanced/detailed approach. AppArmor Denied Operation mount info failed flags match Error 13 provided a starting point for developing a solution.

After incrementally adding rules as new Apparmor DENIED statements occurred, this is the rule set which seems to resolve the errors. Once the container is created, these are the rules I add to the end of /etc/pve/lxc/<vmid>.conf:

lxc.apparmor.raw: mount options=(rw,move) -> /run/credentials/{,**},
lxc.apparmor.raw: mount options=(ro, remount, noatime, bind) -> /,
lxc.apparmor.raw: mount options=(ro, remount, bind) -> /dev/,
lxc.apparmor.raw: mount options=(rw, move) -> /dev/mqueue/,
lxc.apparmor.raw: mount options=(rw, move) -> /tmp/,
lxc.apparmor.raw: mount options=(rw, move) -> /run/systemd/mount-rootfs/proc/,
lxc.apparmor.raw: mount options=(ro, nosuid, nodev, noexec, remount, nosymfollow, bind) -> /run/systemd/mount-rootfs/run/credentials/systemd-networkd.service/,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/sys/net/,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/uptime,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/slabinfo,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/meminfo,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/swaps,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/loadavg,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/cpuinfo,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/diskstats,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/stat,
lxc.apparmor.raw: userns create,

Restart the container, and the errors should no longer occur.

Don't try to place statements in /var/lib/lxc/<vmid>/config as it is over-written by ProxMox upon container startup. Rules are appended to that configuration.

I used the following for a trixie v13.3 version of a container:

lxc.apparmor.raw: mount fstype=ramfs -> /dev/shm/,
lxc.apparmor.raw: mount options=(ro, nosuid, nodev, noexec, remount, nosymfollow, bind) -> /dev/shm/,
lxc.apparmor.raw: mount options=(ro, remount, bind) -> /dev/,
lxc.apparmor.raw: mount options=(rw, move) -> /dev/mqueue/,
lxc.apparmor.raw: mount options=(rw, move) -> /run/lock/,
lxc.apparmor.raw: mount options=(rw, move) -> /tmp/,
lxc.apparmor.raw: mount options=(ro, remount, noatime, bind) -> /,
lxc.apparmor.raw: mount options=(ro, nosuid, nodev, noexec, remount, nosymfollow, bind) -> /run/systemd/mount-rootfs/run/credentials/systemd-networkd.service/,
lxc.apparmor.raw: userns create,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec) -> /run/systemd/namespace-{,**},
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/sys/net/,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/uptime,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/slabinfo,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/meminfo,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/swaps,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/loadavg,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/cpuinfo,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/diskstats,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/stat,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec) -> /run/systemd/unit-root/proc/,
lxc.apparmor.raw: mount options=(ro, nosuid, nodev, noexec) -> /sys/kernel/config/,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec) -> /sys/kernel/config/,

There are many articles available which discuss customizing a pre-existing Proxmox Container Template. Few, if any, discuss constructing an LXC container from scratch. Maybe because, fundamentally, a container template is just the rootfs as tarball, so building it is quite easy:

• Build a linux based virtual machine, I use Debian's recent release
• Install LXC and its template package
• Construct and initialize an LXC container
• Shut it down and and zip it up
• Copy it over to the ProxMox template directory

The details:

# build the linux vm - details not relevant here
# ssh into the vm, or start a command line
# install basic packages

sudo apt install --no-install-recommends lxc lxc-templates xz-utils bridge-utils wget debootstrap rsync

# basic container templates are in:
#   /usr/share/lxc/templates/ 
# for debian as well as other distributions

# create an lxc container, provide a list any additional packages

lxc-create --template debian --name trixie-template -- --release trixie --packages iputils-ping,vim-tiny

# start and attach to the container
lxc-start trixie-template
lxc-attach trixie-template

# prepare for generating template
apt clean
apt purge

# Remove SSH host keys to ensure unique keys for each clone:
rm /etc/ssh/ssh_host_*

# Empty the machine ID file:
truncate -s 0 /etc/machine-id

# clear history
unset HISTFILE
# truncate history
history -c
> ~/.bash_history
# the following has a space in front to prevent inclusion in the history
 shutdown -h now

# the shutdown returns to the virtual machine's prompt
# compress the directory structure

cd /var/lib/lxc/trixie-template/

# remove /dev files as they can't be created in an unprivileged container
# an example error message if not removed:
#   tar: ./rootfs/dev/urandom: Cannot mknod: Operation not permitted
# construction of a new container will re-create the directory and files

rm ./rootfs/dev/ptmx
rm ./rootfs/dev/zero
rm ./rootfs/dev/tty3
rm ./rootfs/dev/urandom
rm ./rootfs/dev/null
rm ./rootfs/dev/tty
rm ./rootfs/dev/console
rm ./rootfs/dev/tty4
rm ./rootfs/dev/tty2
rm ./rootfs/dev/random
rm ./rootfs/dev/tty1
rm ./rootfs/dev/full

# cd into rootfs and zip the container

cd rootfs
tar --xz --acls --numeric-owner -cf /var/local/trixie-13-3-template.tar.xz ./

# the xz file can be copied over to proxmox and placed into
# /var/lib/pve/local-btrfs/template/cache/
# for use as a template for container creation

During the first use of lxc-create to create the original container, packages are downloaded and installed to build the container. The packages and installation is cached for faster subsequent builds of the same container type.

If the cache becomes stale, it can be rebuilt by using --flush-cache in a manner similar to:

lxc-create --template debian --name trixie-template -- --release trixie --flush-cache --packages iputils-ping,vim-tiny,less,python-minimal

An existing cache can be updated with something like:

sudo chroot /var/cache/lxc/debian/rootfs-trixie-amd64
apt-get update
apt-get dist-upgrade
apt-get clean
exit

courtesy of Updating lxc image/container caches

One other note, there are two package candidates for installing the ping utility:

• iputils-ping - native Linux ping, preferred for Debian/Linux
• inetutils-ping - general gnu version, used on a variety of posix sytstems, less preferred

Some fix-ups in the process:

• apt-get install less
• dpkg-reconfigure locales
• useradd user

Something from a Debian mailing list:

I found the root cause, when testing 6.12.57 I installed the image then the headers and the NVIDIA DKMS module was not rebuilt because the matching linux- headers package was not installed at the time the kernel image was configured.

If I install the headers first and then the linux-image package, DKMS correctly builds the NVIDIA module and 6.12.63 works fine, so it doesn't look like a kernel regression after all.

I don't know if I should manually run dkms autoinstall myself after a kernel update (I never had to before) or if there was a bug during the install process of this update.

Makes sense, I had NVidia compile fail in a similar. This makes it obvious what I should have observed.

It has been a while since I last setup NordVPN on a Debian Linux using StrongSwan. StrongSwan is now using 'native' files rather than the now deprecated ipsec files. NordVPN Example: How to connect to NordVPN with IKEv2/IPSec on Linux refers to the old format. Here is a new format.

Here is my take on a successful installation.

apt install \
  --no-install-recommends \
    strongswan \
    libstrongswan-standard-plugins \
    libstrongswan-extra-plugins \
    libcharon-extra-plugins
wget https://downloads.nordcdn.com/certificates/root.pem -O /etc/swanctl/x509ca/NordVPN.pem
sed -i 's/load = yes/load = no/' /etc/strongswan.d/charon/constraints.conf

An example /etc/swanctl/swanctl.conf file:

connections {
  nordvpn {
    version = 2
    proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
    rekey_time = 0s
    fragmentation = yes
    dpd_delay = 300s
    local_addrs = %defaultroute
    remote_addrs = 
    vips=0.0.0.0,::
    local {
      auth = eap-mschapv2
      eap_id = "<username>"
    }
    remote {
      auth = pubkey
      cacerts = /etc/swanctl/x509ca/NordVPN.pem
      id = %any
    }
    children {
      nordvpn {
        remote_ts = 0.0.0.0/0,::/0
        rekey_time = 0s
        dpd_action = clear
        esp_proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-modp3072,aes192-sha256-ecp256-modp3072,default
      }
    }
  }
}

secrets {
  eap-nordvpn {
    id = "<username>"
    secret = "<password>"
  }
}

If you have a local network to which you need access when the vpn is up, StrongSwan using route table 220 for forwarding. Use the following command to see current settings:

# ip rule list
0:      from all lookup local
220:    from all lookup 220
32766:  from all lookup main
32767:  from all lookup default

# ip route list table 220
default via 192.168.1.10 dev eth0 proto static src 

To add your local network to the route table. Additional subnets are added in a similar way. Change the interface name to suit your local circumstances. Use the updown Plugin for better control of the local routing.

ip route add table 192.168.1.0/24 dev wlan0

This may be required for changes made:

# systemctl restart strongswan

Tunnel related state and status commands:

sudo swanctl --load-conns
sudo swanctl --list-conns
sudo swanctl --list-certs
sudo swanctl --list-sas
sudo swanctl --initiate --child nordvpn
sudo swanctl --terminate --child nordvpn
sudo swanctl --reload-settings

References:

• How to Setup an IKEv2 VPN Connection on Arch Linux (Example: NordVPN) - primary configuration template
• Allow Strongswan roadwarrior to access local LAN - keeping local traffic out of the vpn

From Hacker News - %CPU utilization is a lie referencing Brendan Long's Blog

"a server at 60% utilization had zero room left" can be explained with queuing theory:

• Up to a hair over 60% utilization the queuing delays on any work queue remain essentially negligible. At 70 they become noticeable, and at 80% they've doubled. And then it just turns into a shitshow from there on.
• rule of thumb is 60% is zero, and 80% is the inflection point where delays go exponential.
• CPU utilization metrics are frequently averaged over a long period of time (like a minute), but if your SLO is 100 ms, what you care about is whether there's any ~100 ms period where CPU utilization is at 100%. Measuring p99 (or even p100) CPU utilization can make this a lot more visible.

I've done some pre-seeding to be able to auto-install Debian on bare metal and as virtual machines. Using classes is a useful addition for conditional execution of configuration management.

What you probably ought to be doing instead is specifying the option you want via the `classes` setting (an alias for `auto-install/classes`), and then implementing the behaviour you want by setting `preseed/run` in a minimal preseed.cfg, and having a script do whatever you want in response to the classes= setting you specified. So your preseed.cfg would just be:

d-i	preseed/run	string start.sh

and your start.sh would be something like:

#!/bin/sh
. /usr/share/debconf/confmodule

db_get auto-install/classes
db_set preseed/include "${RET:-default}".cfg;;

(you might want to check that the value of $RET makes sense before using it)

Then the real configs go in `default.cfg` and `alternative.cfg` (assuming you're planning on specifying `classes=alternative`)

You may be able to get inspiration from here: https://hands.com/d-i/

although the class handling there is quite deeply buried.

Here's a simpler example of using preseed/run to do odd things to D-I, that while not involving classes, is easier to follow: https://hands.com/d-i/bug/846002/

BTW `auto-install/classes` is reserved for users (it is not used by D-I internally), so it's there specifically for you to implement whatever scheme you like.

Additional information on pre-seeding can be found at B.2. Using preseeding.

A reference for my future self for some interesting troubleshooting capability

When triggering the issue please issue as well a Alt+SysRq+t to dump a list of current tasks and their information to the log. (on systems where you do not have the SysRq key, it might be the PrintScreen one). You need to enable as well debugging dumps, so have to enable it:

echo 8 > /proc/sys/kernel/sysrq

then once you have triggered the crash issue a Alt+SysRq+t and provide the log got over the netconsole.

More information on SysRq key hacks: https://docs.kernel.org/admin-guide/sysrq.html

Lastly, since you have a efi system, we might take as well advantage of logging via pstore. It seems active on your system, so check on next crash please as well /var/lib/systemd/pstore directory for fresh crash logs.

For pstore: https://docs.kernel.org/admin-guide/pstore-blk.html and systemd-pstore.service(8).

... so let's go the bisect route, I will replicate the excellent small howto from Uwe Kleine-Koenig here.

The whole will involve to compile multiple kernels. First we need to prepare a config for your system and to prepare the respective upstream versions, in your case we want to bisect the stable versions in one specific branch, so we can shortcut, and we know we want to bisect changes between 6.12.35 and 6.12.38 in your case.

    git clone --single-branch -b linux-6.12.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
    cd linux-stable
    git checkout v6.12.35
    cp /boot/config-$(uname -r) .config
    yes '' | make localmodconfig
    make savedefconfig
    mv defconfig arch/x86/configs/my_defconfig

As a fist step now compile a local 6.12.35 to ensure it is "good".

    # test 6.12.35 to ensure this is "good"
    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install the resulting .deb package and confirm the problem is not present.

And now the same for the version you suspect is broken, is "bad" for git bisect speach.

    # test 6.12.38 to ensure this is "bad"
    git checkout v6.12.38
    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install the resulting .deb package and confirm the problem with audio exists.

So we have now a range of from good to bad kernel and we can start the bisect:

    git bisect start v6.12.38 v6.12.35

    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install, try to boot and verify the state of the problem

and if the problem is hit run:

    git bisect bad

    git bisect good

Please pay attention to always select the just built kernel for booting, it won't always be the default kernel picked up by grub.

Then provide the output of

    git bisect log

In the course of the bisection you might have to uninstall previous kernels again to not exhaust the disk space in /boot. Also in the end uninstall all self-built kernels again.

Learned a new detail command for USB port details.

The below is a listing from an Asus X670e motherboard. Notice that the command provides port speeds (which implies a USB port type, which may be dependent upon capability/type of device connected). And yes, I still have a Microsoft 4000 keyboard. I wish they still made them. Extremely comfortable and has an excellent layout. Any good places to find them?

$ lsusb -vt
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 002: Dev 002, If 0, Class=Audio, Driver=snd-usb-audio, 480M
        ID 0424:3fb7 Microchip Technology, Inc. (formerly SMSC)
    |__ Port 002: Dev 002, If 1, Class=Audio, Driver=snd-usb-audio, 480M
        ID 0424:3fb7 Microchip Technology, Inc. (formerly SMSC)
    |__ Port 002: Dev 002, If 2, Class=Audio, Driver=snd-usb-audio, 480M
        ID 0424:3fb7 Microchip Technology, Inc. (formerly SMSC)
    |__ Port 002: Dev 002, If 3, Class=Audio, Driver=snd-usb-audio, 480M
        ID 0424:3fb7 Microchip Technology, Inc. (formerly SMSC)
    |__ Port 006: Dev 003, If 0, Class=Wireless, Driver=btusb, 480M
        ID 0489:e0e2 Foxconn / Hon Hai
    |__ Port 006: Dev 003, If 1, Class=Wireless, Driver=btusb, 480M
        ID 0489:e0e2 Foxconn / Hon Hai
    |__ Port 006: Dev 003, If 2, Class=Wireless, Driver=btusb, 480M
        ID 0489:e0e2 Foxconn / Hon Hai
    |__ Port 007: Dev 004, If 0, Class=Vendor Specific Class, Driver=[none], 12M
        ID 0b05:19af ASUSTek Computer, Inc.
    |__ Port 007: Dev 004, If 2, Class=Human Interface Device, Driver=usbhid, 12M
        ID 0b05:19af ASUSTek Computer, Inc.
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/5p, 20000M/x2
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/:  Bus 005.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
/:  Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/5p, 20000M/x2
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/:  Bus 007.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
/:  Bus 008.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/:  Bus 009.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 002: Dev 003, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        ID 045e:00db Microsoft Corp. Natural Ergonomic Keyboard 4000 V1.0
    |__ Port 002: Dev 003, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M

One wouldn't normally associate these together, but after encountering the pebble in the shoe for far too long, it is nice to have a 'mostly' resolution.

My first introduction to the wonders of Wayland was when I assembled my new computer based upon the Asus ProArt X670E-CREATOR WIFI motherboard (motherboard works just fine) and installed Debian Trixie with the KDE windowing system. In this install, the default rendering manager is Wayland. For a user running a single monitor and a single virtual desktop, this is probably the cat's meow.

However, having used LXDE with virtual desktops, and when ever restarting Firefox, all my multitude of FireFox windows were placed in their original positions on my multiple monitors and across my virtual desktops. Trying to do this in the world of KDE/Wayland turned out to be impossible.

My interim solution was to create a Firefox profile for each virtual desktop. At least that provided the ability to keep the windows local. It also reduced the number of windows in each profile, and accessing content was a bit snappier, as there were fewer windows. I don't know why multiple windows will slow down Firefox, but it started back in the v90's I think.

Then when I installed an NVidia RTX 5070 TI, and moved my monitors over to it, my mouse got shaky and stuttery. Some forum users suggested disconnecting and reconnecting one or more video cables may shake the problem loose. This was not a solution for me.

I was thinking that Wayland was my only option and there was no going back to X11. But yes it was possible. I simply needed to logout, choose a setting in tiny print in the lower left of the screen and select X11.

When logging in with X11, the mouse stuttering stopped.

And by happenstance, when I brought Firefox back up with all the windows, the Windows started shifting over to their original locations.

Prior to this, I didn't know: Wayland doesn’t let applications set their position, but it does allow them to set their size - so that is why I can't restore my Firefox windows to their original locations.

Wayland's positioning problem leads to a KiCad remark: KiCad's development team recently came out saying Wayland was feature poor and kind of buggy which results in their application not running well on it. Some of it due to this window placement problem.

Overall, my primary problems have disappeared, but I find that running three 4K monitors off an RTX 5070 Ti in X11 mode, everything appears a bit 'laggy'. Next weekend, I'll switch my monitors back to the on-board Video and see if the lag is more or less.

One of the reasons for moving the monitors to the NVidia card was that when monitors went into sleep mode when I was away from the computer, a few apps including a couple Wine based apps had their windows closed. Now, if I move back to the onboard video card, and retain monitor power-off, I'll see if this works.

And at the same time, maybe I can save an extra 30W that nvidia-smi says it consumes when driving my monitors.

Note, I got the NVidia card, not for gaming, but for running PyTorch/libtorch based simulations.

As a side note, there is a world of difference when running nvidia-settings when in Wayland mode and when in X11 mode.

One more reminder for myself, to use the NVidia card for monitors instead of the onboard video card, this was needed:

cat /etc/modprobe.d/nvidia.conf                                                                                                                                                                                                          
options nvidia-drm modeset=1

With the following note:

Setting modeset=1 doesn’t actually install a framebuffer console. All it really does is enable the DRIVER_MODESET capability flag in the nvidia-drm devices so that DRM clients can use the various modesetting APIs. In addition to allowing clients that talk to the low-level DRM interface to work, it’s also necessary for some PRIME-related interoperability features.

The downside, if you want to call it that, is that loading nvidia-drm with modeset=1 causes it to configure and initialize all GPUs immediately rather than waiting for a client to open the /dev/nvidia* device files. This means that some options that require a userspace application to configure them before the GPUs are initialized won’t work if they were already configured by nvidia-drm. The big example at the moment is SLI Mosaic, which is enabled by the X driver if /etc/X11/xorg.conf says it should be.

Resources:

• Wayland does work and does stuff people claim it can’t - long discussion of Wayland capabilities and non-capabilities
• Wayland + Firefox, can’t restore windows to correct location - others have had my problem with Firefox windows returning to position when using Wayland