Read the man page for env.

#!/usr/bin/env python3

Will only work if python3 is in it's $PATH. Try which python3 to make sure it's installed on your system.

First try running memtest86 for a few hours. Run it single threaded first. If it doesn't hang or report any faults try it again multi threaded. If memtest86 crashes as well then the OS must be innocent.

Next boot Linux and run watch sensors in a terminal window. That will show how hot the CPU etc are. If it gets over 100C then check all fans are OK, there's no fluff on the CPU, etc.

I've just found (from an article in Linux Magazine) that there's a program called adequate which sanity checks packages for violations of Debian package guidelines.

Install with apt-get install adequate and read it's man page for details (it won't usually need to be run as root). From a quick check it should find various packaging errors, although there can be false positives. And it only checks if a package is correctly packaged, not if it actually does what it is supposed to. But it looks worth adding to recommended workflow.

Does the path to the directory have spaces in it? That could confuse things.

Try:
ls -A  /media/charon/seagate backup plus drive/dr web
If that gets similar errors try:
ls -A '/media/charon/seagate backup plus drive/dr web'
Putting quotes round the path should stop spaces in the name causing problems.

Assuming the directory really is empty (ls -A should return nothing if it is empty) try:
rmdir '/media/charon/seagate backup plus drive/dr web'

And similar for renaming directories.

When you see an example command starting with a $ don't enter the $, just the rest of the command. It's usually the terminal prompt.

In the unlikely event you did need to enter the $ the poster would tell you explicitly.

How much memory does the system have? It might well be that systemd uses a LOT more memory, so the system starts page thrashing.

Either way it's nice to have another objective argument against systemd.

If you can't log in to the GUI try ctrl-alt-f1 (press all 3 keys at once, in that order) which should get you to a text console where you can log on and try to fix things.

Next time you try to install something *always* do a simulation run first and check what it says it's going to do.

Should you have non-free-firmware in your sources.list? I don't think that would cause this problem but might cause problems with hardware support later.

I suspect the PREEMPT_DYNAMIC kernel. I have one system I use to run CUDA (on a Nvidia card) where I have to boot it with the default kernel, not the preempt one, to get CUDA to work.

If you have an option to boot the 6.1 default kernel could you try it to see if that's the problem?

It's not essential for CUDA either. Both the CUDA apps I use (gmp-ecm and msieve polynomial selection) work without it running.

I have got a system that runs CUDA on the GPU, but uses the onboard graphics to run the display. (It shares a monitor with 3 other systems via a KVM switch.) But for historical reasons it runs openSUSE 15.3 so I'm not sure how much I can help, beyond saying it is possible on some systems.

It has a GeForce GTX 970 with CUDA cuda-drivers-510 but a rather old motherboard (can't find the manual right now) in case that helps.

The message probably refers to /home/ziomario/.ssh/config on the system you are connecting from, not on the destination.

My advice to anyone with a similar problem would be to try ssh -v which would produce a lot more messages from ssh, which should tell you enough to solve the problem. If still stuck post *full* output here which should give us enough information to work out what the problem is.

I learnt that debuging ssh problems at work (although we had enough different OSes and ssh versions thatgetting them all to work properly took quite a while).