The small linux problem thread

Anyone want to write or know where I can find an application that reports what process ID is adding to the X clipboard?

I saw some code on stackoverflow - might try to do soon, but this clipboard issue is driving me nuts. I disabled ghostery and self-destructing cookies in firefox - that helped (also enabled pfsense blocker equivalent of pi-hole to replace some of that functionality).

That has the blasting of my clipboard down to a dull-roar, but I still have to clear my Klipper app in KDE every 10 minutes or so or cut and paste gestures in emacs don’t work (because the clipboard is overrun with garbage). XClipboard randomly shows 10’s of thousands of items dumped to the clipboard for no apparent reason. While it shows a count - it often shows no new content, so I can’t identify the source of these clip events.

Hoping that an app logging what’s dumping will help me file a bug - someone has done something horrible, but I don’t know who…

Suspects are:
SELinux reporting app - I’ve disabled alerts, yet I still get them in my task bar.
Firefox (or plugins - ublock still running)
KDE
I suppose one of the gtk apps I’m running (psenseor) might be doing something odd? They certainly spam the terminal with oddities now and then if I launch from an xterm.

It’s rendered my desktop as frustrating to use as windows… I’ve been using linux as my primary desktop OS for nearly 20 years, I’ve never run into something this infuriating yet difficult to solve.

Don’t want to have to go back to gnome… It’s too locked down and wasteful of screen space. I use a 4K screen because I need those pixels and don’t want to waste 50 them on cartoonish window decorations and giant task bars.

Very strange.

Can you run dmesg (as root) when the machine is stalled and see if it reports anything useful?

I have a Ryzen 7 1800x based system running Linux (Slackware-current) which has very few issues now.
Mine is on an ASRock X370 Taichi MB, Seasonic PSU (can’t remember exact model), and Radeon GPU.

Anyway, I seem to recall some very recent kernel fixes for Ryzen USB issues. Can’t find the details now, of course.
I’m still rocking a PS/2 KB & mouse via a PS/2 Y cable, so haven’t used the USB ports much.

Also, be aware that some Ryzen CPUs have a +20degree offset on reported temperature.

That’s actually exactly what I did. No macvtap involved.

I added the second NIC and created a bridge attached to it. This works perfectly, as the VMs can use the bridge and have access to the physical network and can be assigned unique IPs based off of unique MAC addresses. Fantastic.

However, it breaks SSH and VNC for the primary NIC/IP address. I can’t access the server via SSH or remote desktop anymore.

Do the physical ports have the same MAC address as the VMs? I believe that’s what macvlan is for: adding more MAC addresses for virtual ports at layer 2. I haven’t tried this myself since I’m using layer 3 routing for containers, like this: https://docs.cumulusnetworks.com/display/ROH/Routing+on+the+Host

No, the VM MACs are different from any physical adapter. Maybe it is done via macvlan, even though it doesn’t say it is when selected. Don’t know. When I created the bridge and attached it to the second NIC the NIC itself cannot be used (it does not get an IP), but the bridge does. This is normal behavior? In virt-manager I can tell each VM to use the bridge, and they get a random generated MAC. I can use this MAC to assign a static IP via pfSense to each VM, which is exactly what I wanted to do.

I’m thinking the reason SSH and VNC don’t work (or stopped working) on the host is because the second NIC is named a lower number and the primary was changed to a higher number (enp3s0 and enp4s0). The primary was 3 before adding the second NIC, and I have no idea why they switched. Could this be the cause?

I actually figured out a fix for SSH. I went into sshd.config and told it to listen on the host IP. This allows me to connect to the host via SSH now. I am not sure how to do something similar for VNC for the built in remote desktop in Fedora.

It is normal that the bridge has the IP and the NIC does not.

When there are more than 1 routes to the same network, Linux will use “equal cost multi-path” (ECMP) routing rules to select a path. The rule which it chooses is this sysctl:

fib_multipath_hash_policy - INTEGER
	Controls which hash policy to use for multipath routes. Only valid
	for kernels built with CONFIG_IP_ROUTE_MULTIPATH enabled.
	Default: 0 (Layer 3)
	Possible values:
	0 - Layer 3
	1 - Layer 4
$ sysctl net.ipv4.fib_multipath_hash_policy
net.ipv4.fib_multipath_hash_policy = 0

Layer 3 means that the IP address is used to hash the link. Using layer 4, the TCP/UDP port and the IP address is used to hash the link. This presumes that both NICs have a route to the network… if one doesn’t have an entry in “ip route show”, then it won’t be used by this layer 3 redundency mechanism (ECMP).

But… there must be a switch or a router at the other end that will also do ECMP routing. Without that, then this won’t work. The macvlan method uses a different routing mechanism at layer 2, which does not require any layer 3 routing since it uses MAC addresses to select the path. Both of these things are relatively new, the classic way of doing redundency is to trunk both ports together so that the switch and the host are aware and treat both wires as a single link (using MACs to hash and select the physical link).

edit: maybe you can get it to work, without ECMP at the other end, I’m not sure. Usually, ECMP is used with bridges that are routable and not on the same network as the NIC, for example:

eth0: 192.168.1.1/30 -> 192.168.168.1.2/30 -> internet
eth1: 192.168.1.3/30 -> 192.168.168.1.4/30 -> internet
br0: 192.168.2.1/24
vm0: 192.168.2.2/24
vm1: 192.168.2.3/24

Both eth0 and eth1 are diffent networks but the route to the internet can be reached through either of them.

Linux networks are wonderous things, there are many ways to do stuff and many ways to frack it up.

I am trying to get fre:ac to work on my Mint 18.2 install. Downloaded it, put the folder in my home directory (there is no proper installation method yet) and double-clicked the executable … but nothing happened. I checked the properties and it is marked as executable, but somehow it doesn’t run.

A bit of Duckduckgo-ing later, I ran the ldd command and it looks like I’m missing a dependency, libcurl.so.4 to be precise. But how do I get and install that?

sudo apt install libcurl3?

1 Like

Ah, libcurl3? I assumed it would be 4 and tried that, but to no avail. Will try it as soon as I’m back home (10 mins or so)

1 Like

Should be. Granted i tested in a debian docker container but packages tend to share similar names thankfully :smiley:

1 Like

Yup, that did the trick. Dependency is okay now and fre:ac opens when I double-click it. Thank You!

2 Likes

No problem. Glad to help :smiley:

2 Likes

had a pgp keyring issue from not updating my laptop for a week, solved it with


wanted to post this for if I run into the same issue in the future

s: signature from Antergos Build Server (Automated Package Build System) <[email protected]> is invalid 
:: File /var/cache/pacman/pkg/antergos-desktop-settings-1.7-1-any.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). 
Do you want to delete it? [Y/n] 
error: failed to commit transaction (invalid or corrupted package) Errors occurred, no packages were upgraded.

use this

sudo pacman -Scc
sudo pacman-key --refresh-keys
sudo pacman -Syu
2 Likes

You occasionally get this with pacman distros regardless of the update frequency. It’s not about update frequency but key expiry.

But yes, that is the correct method to repair the keystore.

3 Likes

found my solution, just posting it here so that I can reference back to it should I need to reinstall discord
discord throws this error when installing it


source

==> Verifying source file signatures with gpg...llvm-6.0.0.src.tar.xz ... 
FAILED (unknown public key 0FC3042E345AD05D)libcxx-6.0.0.src.tar.xz ... 
FAILED (unknown public key 0FC3042E345AD05D)libcxxabi-6.0.0.src.tar.xz ... 
FAILED (unknown public key 0FC3042E345AD05D)

solution is to use

gpg --recv-keys 0FC3042E345AD05D 8F0871F202119294

should solve the gpg key issue

1 Like

Apologies for the imposter BSD post.

Does anyone know the breakdown of FreeBSD’s versioning?

For example:

FreeBSD 11.1-RELEASE #0 r321309

What is #0 r243825?

This appears in sysctl kern.version (so also in uname -a or uname -v).

I’m mainly looking for the revision number or rough equivalent. Not sure to go with r243825 or 1101001 from sysctl kern.reldate or if those correspond. And no idea how the #0 factors in.

I know FreeBSD also previously listed a patch number after RELEASE (ex: FreeBSD 9.2-RELEASE-p4 #0), but I don’t know if they’re still doing that or what.

2 Likes

Distro installs last ~2 days, then login loop.

Ryzen 7 1700x
32GB DDR4
GTX1070

I have to install 'buntu flavored distros using nomodeset, boot once with nomodeset, then install Nvidia proprietary drivers. No problem there. Install runs perfectly for a few days, then after restarting I get login loops. This happens on Pop OS, 'Buntu, etc.

Problem doesn’t happen using Fedora, but I likely my debian based distros. Any thoughts?

Things I’ve tried (in CTRL+F4 terminal)
tweaking .Xauthority
apt upgrade/apt dist-upgrade
updating Nvidia driver (already current)
installing LightDM (which works to log in but causes new problems, since I usually use gnome or cinnamon)

sounds like the nvidia driver shitting over wayland. Can you confirm whether or not the login loops happen with nomodeset

Will be home soon to check and let you know.