It's been fine since! I should probably update it again, but that's another task's task.

I was about to be like "well this has been working fine for ages now, time to close this task!" and then I noticed my comment above and yeah, /etc/cron.hourly/kludge is still marked executable. So uhh lets disable that and see if things remain stable before I hang up the Mission Accomplished banner...

I should work https://daniel.haxx.se/blog/2023/03/02/the-curl-nuget-story/ in here

Sounds like it has been solid ever since, so that must have been it? Or perhaps something else coincidentally changed, I suppose. But for now this awaits a newer firmware version to try and see if it resolves or resurrects the problem.

https://jointakahe.org/ might be worth checking out

Video testing using YouTube mostly in Chrome but also a bit in Firefox hasn't crashed it on @pwrightlindl's PC yet since downgrading to firmware version 2803 . . .

As @pwrightlindl noted in chat, it's a real crapshoot of solutions out there. For example:

This worked for me! I was able to fix it increasing my DRAM voltage by a little (0.3), not the full 0.05 as recommended in the post.

https://linustechtips.com/topic/1409230-pc-hard-reset-on-both-windows-and-linux-error-type-cache-hierarchy-error-solved-rma/ does mention having the problem occur on Linux as well, and also mentions, intriguingly,

I have disabled Core Performance Boost(CPB) which "solved" my issue.

https://www.asus.com/motherboards-components/motherboards/prime/prime-b550m-a/helpdesk_bios/?model2Name=PRIME-B550M-A lists the most recent firmware versions as

Keeps dying; checking the Pleroma service log via journalctl gives me

Keeps dying; checking the Pleroma service log via journalctl gives me

Rebooting the entire system worked, which . . . oof. I don't like that one bit.

Haven't seen it go as bad as that again, but I'm still getting the

Well damn

Everything seems fine so far? Closing this issue again, but warily . . .

wait nevermind it's done already, guess my extreme upgrade last time gave me the wrong impression about how long it'd take haha

Alrighty, got the pleroma and nginx (just because I like shutting that fucker down) services stopped and I'm running the database upgrade from https://docs.pleroma.social/backend/administration/updating/#for-otp-installations now . . .

Majority of downtime so far just taking the snapshot before upgrading Pleroma (I didn't before upgrading the OS lol).

Ah, hmm, I'll actually have to upgrade to 22.04 after all, at https://git.pleroma.social/pleroma/pleroma/-/releases or more specificaly https://git.pleroma.social/pleroma/pleroma/-/releases/v2.5.0 it says

Wait why is snapd using some godawful amount of CPU, honestly why is snapd even running is that how I have Elixr running or something?! The two hogs seems to be snapd and kswapd0, and I can't help but suspect the former is sprawling with its containerized nonsense and triggering the need of the latter, though that could easily be my anti-container bias showing.

Opening this up again because I keep getting timeouts and random loading errors on 2.4.5 so I'm gonna upgrade to 2.5.0 and hope that fixes things.

Had to use the pleroma.nginx config shipped with the latest version and port over my few domain-specific options into it, but now it seems fine! I'm on 2.4.4, which according to https://pleroma.social/announcements/ seems to be the latest stable release, done 2022-05-08. Okay! Maybe I'll upgrade the server to 22.04 sometime but lets just leave well enough alone for now.

Service thinks things are fine?

● pleroma.service - Pleroma social network
     Loaded: loaded (/etc/systemd/system/pleroma.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2022-11-21 22:54:51 UTC; 36s ago
   Main PID: 898 (beam.smp)
      Tasks: 25 (limit: 1066)
     Memory: 199.1M
     CGroup: /system.slice/pleroma.service
             ├─ 898 /opt/pleroma/erts-10.7.2.18/bin/beam.smp -- -root /opt/pleroma -progname erl -- -home /opt/pleroma -- -noshell -s elixir start_cli -mode embedded -setcookie DEFIM7M3ZQNSRB5AGUT5Y437SRKORNIG7O7DNAPINZXHVZCNDKIA==== -name pleroma@127.0.0.1 -config /opt/pleroma/tmp/pleroma-2.4.4-20221121225451-f0db.runtime -boot /opt/pleroma/releases/2.4.4/start -boot_var RELEASE_LIB /opt/pleroma/lib -- -extra --no-halt
             ├─ 933 /opt/pleroma/erts-10.7.2.18/bin/epmd -daemon
             ├─ 937 erl_child_setup 1024
             ├─1084 /opt/pleroma/lib/fast_html-2.0.4/priv/fasthtml_worker
             ├─1085 inet_gethost 4
             ├─1086 inet_gethost 4
             ├─1101 /opt/pleroma/lib/majic-1.0.0/priv/libmagic_port
             └─1102 /opt/pleroma/lib/majic-1.0.0/priv/libmagic_port

Or, wait, that was it?

We've reached February of last year:

Oddly enough it restarted just fine afterwards?

A surprise challenger has appeared, upgrade stalled out at

Hmm I never have luck with PostgreSQL but maybe today's the day that changes...

https://docs.pleroma.social/backend/administration/updating/ seems to be the official update instructions, I'm pretty sure I'm an "OTP installation" rather than Git, so I go:

May as well collect some options for *setting* the colors:

• https://askubuntu.com/a/153493 and https://archive.ph/QSYHd set within bash
• Using setvtrgb: https://lists.altlinux.org/pipermail/kbd/2011-March/000287.html
• I gather tput can do this and also could be fun for scripting fancy CLI displays http://linuxcommand.org/lc3_adv_tput.php

Haha yup that was it! This solved things:

I tried kmscon, which instantly gave me colors in the normally colorless default shell sessions on ubuntu-server, but didn't solve this.