Headless remote desktop is nice as well

How did I not know about this? Thanks!

Just lazy

Sounds like a graphics driver issue. does anyone know if mint enables ssh by default?

How did it go?

Reisub and ctrl+alt+del spam needs to be configured, and system rebooted in order to work first.

Explain how “freezed” are the system

• is the freeze sudden or does the system gets progressively slower?
• does the mouse cursor respond?
• does the audio keep playing in the background? does it repeat a short time interval over and over again?
• does the system respond to ping requests?
• does the system accept incoming ssh connections?
• how random is it? what time interval?
• is the location random (think consistent wifi / bluetooth devices nearby)
• is the freeze happening after going to sleep / hibernation / screen blank?
• does this happen if you aggressively open a lot of apps at the same time? Try it.

What to do before next system freeze

• update and upgrade the system
• create a working directory somewhere where you write down your findings. Does not have to be pretty or anything. Just for your own convenience.
• Configure REISUB. check files in /etc/sysctl.d/*.conf and look for kernel.sysrq=0. Change it to 1.
• Enable ctrl+alt+del spam reboot. Update /etc/systemd/system.conf so that you have a line looking like this:

CtrlAltDelBurstAction=reboot-force

• Reboot
• Try spamming ctrl+alt+del quickly. Does the system reboot?
• On next boot try switching to a random tty ctrl+alt+fN where N in {1…12}. You should see a login prompt. Try the REISUB sequence. Press and hold alt+print screen (might require some fn key combination on a laptop) then press, hold and release following letters one at a time: R E I S U B. You should see kernel messages appear on the screen each time you press a button. Don’t try to press them all at once or type them before the output is finished. Your system should reboot after this. Does it work?
• make sure you can ping your computer from another computer.
• Configure TCPKeepAlive=no for my-faulty-pc in your ssh config before connecting to avoid having the connection dropped. then run ssh my-faulty-pc journalctl -b0 -k -f > waiting_for_crash.log on another system that will capture the log

reproduce Here is the easiest part. Make the system hang. Preferably with reproducible steps.

System is now freezed

• Go quickly through the first list
• from the remote host that monitors the logs through ssh. You can close the ssh connection and inspect some of the last lines in the file. Don’t upload it anywhere before sanitizing it to avoid doxing yourself.
• from the remote system try ssh and pinging.
• on the frozen host try ctrl+alt+del burst first
• then try REISUB combo if the burst didn’t work.

What to do now This part depends a bit on what the outcomes were. At least we’ll know how “deep” the hang is and where it’s worth modifying stuff.

You say in your post that you’ve tried ctrl+alt+del spam. But did you check that it works when the system is working as intended?

Edit: minor typo

deleted by creator

If you have redundant runtimes then you have to push app developers to update their runtime. This problem will not go away by switching to native packages unless native packages and flatpak versions are not in sync.

Is it such a hassle learning verilog if you know vhdl or vice versa?

Nice one, didn’t know about moreutils. I indeed used p10k on top of zsh. New zsh instance without sourcing anything zsh --no-rcs managed to write to file without issues. Thanks

yep. that did it. I had to wrap the entire thing in quotes though

sh -c "echo 'test' | sudo tee newfile"

no way. I’m in /tmp for this one

echo 'test' | tee newfile
tee: newfile: Permission denied
test
echo 'test' | sudo tee newfile #the prompt never returns when running this in zsh

sudo does not prompt for password in my container. It just elevates the privileges straight away. Yeah, it’s hard to tell. Or test for that matter.

what I was saying was that echo "text" | sudo tee newfile would hang and never return and needs to be interrupted. I just noticed this does not happen in bash but I was testing in zsh.

Guessing that file doesn’t exist already is the problem, and you don’t even need to use tee in this example.

you’ve missed the point here I’m afraid. But I’ll blame it on my for not explaining properly what I was intending to do.

I just switched over to bash and it worked lol. It just didn’t return for me in zsh…

yeah indeed. I’m setting up a container with these instructions for ROS2. There you’ll have to add a repository to the apt sources list.

VM behind a VPN with a firewall that blocks everything except the rdp protocol and no sudo access?

What I see is that someone is arguing the point that all Russians are criminals. If someone is sending bad code, they usually just get banned, this time it’s preventive measures based on ethnicity.

This is such an odd thing to do… I really cannot see the benefits for the project doing this. Maybe those maintainers were payed for their work and sanctions prohibit paying them or something?