If the ID has the same name, UID and GID then  --numeric-ids won't make any difference.

Try an experiment copying a small directory with various options and see how it works.

It won't matter if on both systems the users have the same numeric UID and GID. But it will make a difference if the users have different UIDs or GIDs. Check /etc/passwd on both systems to see what is likely to happen.

Eg if chris has UID 1000 on the source system and UID 1001 on the target you don't want to use --numeric-ids.
But if the names differ but have the same UID (eg chris is UID 1000 on source and fred is UID 1000 on the target (chris doesn't exist on it)) --numeric-ids would leave everything owned by fred.

I hope that's enough to let you understand what difference it would make.

After seeing the first set of messages I'd start by checking if /lib/elogind/elogind-uaccess-command /dev/sr0 and /dev/sg1 exist. Assuming they do I'd run file /lib/elogind/elogind-uaccess-command to see what it is.

If it's a script I'd check if the interpreter (usually on the first line) exists.
If it's an executable I'd run ldd against it to see what shared libraries it uses.

HTH

Which country are you in and which ISP do you use? It sounds as if it's only affecting some users.

Next time it happens try:
host deb.devuan.org - you should get a list of IP addresses.
ping deb.devuan.org - this will pick one of the list at random. Look at the response time (the last field).
traceroute deb.devuan.org - shows what path connects to the one it picks. Or how far the traffic gets if it doesn't respond.

That should give you a bit more to go on. You could ping each address in the list to see which ones work for you.

If you find some of the addresses always work you could put one into your /etc/apt/sources.list (preferably one in the same country as you).

Have another look at that thread.

If host deb.devuan.org works try ping deb.devuan.org
If ping fails try ping deb.rr.devuan.org (a long shot but worth trying).
If that also fails try pinging each of the IP addresses returned by host deb.devuan.org in turn. If one gets a response run host address eg:

chris@rigel:~/bin$ host 185.38.15.84
84.15.38.185.in-addr.arpa domain name pointer sledjhamr.org.

Then *temporarily* put the name returned into your sources.list (take it out again once the issue is fixed) and try apt update

Or post in the other thread to see if anyone else can help. It might be your ISP has messed up so post what ISP you use and which country you are in.

See https://dev1galaxy.org/viewtopic.php?id=6781 which is probably the same issue.

To check what driver is being used for your nvidia card:

chris@rigel:~/bin$ lspci | grep -i nvidia
01:00.0 VGA compatible controller: NVIDIA Corporation GF104 [GeForce GTX 460] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GF104 High Definition Audio Controller (rev a1)

Check the video card as follows (updating the address if necessary).

chris@rigel:~/bin$ lspci -v -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GF104 [GeForce GTX 460] (rev a1) (prog-if 00 [VGA controller])
	Subsystem: Gigabyte Technology Co., Ltd GF104 [GeForce GTX 460]
	Flags: bus master, fast devsel, latency 0, IRQ 34
	Memory at f4000000 (32-bit, non-prefetchable) [size=32M]
	Memory at e8000000 (64-bit, prefetchable) [size=128M]
	Memory at e4000000 (64-bit, prefetchable) [size=64M]
	I/O ports at ac00 [size=128]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: nvidia
	Kernel modules: nvidia

The last two lines should say nouveau if that's being used (I'm using the nvidia driver so I can run CUDA apps on the card).

Could some moderator please move this thread to Off-topic ? It has nothing to do with Devuan.

What country are you in? There was problem affecting several banking sites in the UK yesterday. So it might not be firefox (although it probably is if it affected other sites as well).

Running shellcheck against wondershaper would be a reasonable start if it's a shell script.

Then try adding set -x as the second line and see if that tells you what it's trying to do when it fails.

But I'm only guessing because I don't have wondershaper installed.

Re post 89 by soren (at 09:32:57) my first response would be:
ls -li /lib/x86_64-linux-gnu/libsystemd.so.0 /usr/lib/x86_64-linux-gnu/libsystemd.so.0
and see if one was a symlink to the other or if they are hard links (same inode numbers). If different files but the same size I'd then try diff /lib/x86_64-linux-gnu/libsystemd.so.0 /usr/lib/x86_64-linux-gnu/libsystemd.so.0 to see if one is a copy of the other.

If they are the same inode numbers I'd check if /lib and /usr/lib are symlinks (ls -lid /lib/x86_64-linux-gnu/ /usr/lib/x86_64-linux-gnu/ then ls -lid /lib/ /usr/lib/). That would give me a better idea what state things are in.

It's probably a bit late now, but did you save a copy of /home/groucho/.wine from before you restored it from the snapshot? Or just output from ls -lr /home/groucho/.wine ? Comparing permissions from then and now might show what was wrong.

If anyone else hits this issue that would be worth trying.