Ah, fair enough. Long shot, but thought I'd at least mention it on the off chance that maybe it would work and maybe you hadn't yet tried it. Sorry.

tries to think of anything else that could be done

Are you using Linux? Linux has a patch that was added many years back with the ability to map around damaged regions in memory. I mean, if your memory is completely hosed and you can't even boot the kernel, then that won't work, but if you can identify specific areas that fail, you can hand that off to the kernel and it can just avoid them. Obviously decreases usable memory by a certain amount, but...shrugs

I've never needed to do it myself, but let me go see if I can find some information. Think it was the "badram" feature.

searches

Okay. You're running memtest86. It looks like that has the ability to generate the string you need, and you hand that off to GRUB, which hands it off to the kernel.

https://www.memtest86.com/blacklist-ram-badram-badmemorylist.html

MemTest86 Pro (v9 or later) supports automatic generation of BadRAM string patterns from detected errors in the HTML report, that can be used directly in the GRUB2 configuration without needing to manually calculate address/mask values by hand.

To enter the address ranges to blacklist manually, do the following:

Edit /etc/default/grub and add the following line:

GRUB_BADRAM=addr,mask[,addr,mask...]

where the list of addr,mask pairs specify the memory range to block using address bit matching
Eg. GRUB_BADRAM=0x7ddf0000,0xffffc000 shall exclude the memory range 0x7DDF0000-0x7DDF4000
Open and terminal and run the following command

sudo update-grub

Reboot the system

If you can't even boot the system sufficiently to get update-grub to run, then you might need to do a fancier dance (swap drive to another machine or something), but that's probably a good first thing to try. I'd try booting to "rescue mode" or whatever if your distro has an option like that in GRUB, something that doesn't start the graphical environment, as it'll touch less memory.

EDIT: If your distro doesn't have something like that "rescue mode" set up --- all the distros I've used do, but that doesn't mean that all of them do --- or it it can't even bring "rescue mode" up, because your memory is too hosed for that --- then you probably want to do something like hit "edit kernel parameters" in GRUB and boot while adding "init=/bin/bash" to the end of the kernel command line. That'll start your system up in a mode where virtually nothing is running --- no systemd or other init system, no graphics, no virtual consoles, no anything. Bash running on bare metal Linux kernel. Control-C won't work because your terminal won't be in cooked mode, everything will be very super-duper minimal...but you should be able to bring up bash. From there, you'll want to manually bring your root filesystem, which the kernel will have mounted read-only, as it does during boot, up to read-write, with:

# mount / -o remount,rw

Once that's done, do your editing of the grub config file in vi or whatever, run the update-grub command.

Then run:

# sync

Because you don't have an init system running and it's not gonna flush the disk on shutdown and your normal power-down commands aren't gonna work because you have no init system to talk to.

Go ahead and manually reboot the system by killing its power, and hopefully that'll let it boot up with badram mapping around your damaged region of memory.

EDIT2: It occurs to me that someone could make a utility that can run entirely in Linux to do memory testing to the extent possible inside Linux using something like memtester instead of memtest86, generate the badram string and then write it out for GRUB. That's less bulletproof than memtest86 because memtester can't touch every bit of memory, but it's also easier for a user to do than the above stuff, and if you additionally added it to the install media for a distro, it'd make it easier to run Linux on broken hardware without a whole lot of technical knowledge. I guess it'd be pretty niche, though --- doubt that there are a lot of systems with damaged memory floating around.

EDIT3: Oh, that's only the commercial version of memtest86 that will auto-generate the string. Well, if you know how to do a bitmask and you can get a list of affected addresses from memtest86, then you can probably just do it manually. If not, post the list of addresses here and someone can probably do a base address and bitmask that covers the addresses in question for you. Stick the memory back into your computer first, though, since the order of the DIMMs is gonna affect the addresses.

Unless it's ddr5 check your local ewaste recyclers, most have shops where you can buy used parts.

What kind of RAM? DDR4? I can sell you old G Skill DDR4.

I have an old team force ddr4 16gb kitm not exactly top of the line but should do the trick. I'll gladly sell it to you for a much fairer price than what's around these days long as you're in the us. dm me if interested, no worries if not

Ah too bad, I'd have sold you the RAM at a great discount (~50€)

Then what's the fucking problem? Just buy more RAM.

Idk I just bought a 32GB stick of ddr4 sodimm for $60, adapters are less than $10 each so maybe not if you stay away from scalpers and don't pay attention to ram speed 😅

I was also thinking the soldered CPU motherboard with 8 cores must cost at least 200 but maybe that's a bad assumption and I didn't look it up.

It could be the board, it could be the RAM, and it could be a fauly memory controller on your CPU. Although, if this was a while ago (pre-2003 for AMD, pre-2008 for intel) then the memory controller would be on the ASRock board.

In other words, a nightmare to diagnose.

Interesting. I actually read stuff like that related to Asrock boards and never used them. Sounds like I made the right choice.

Hm, sounds like it. Micron is certainly reputable, and the issues hints at memory, although I've had similar that turned out not to be ram. Certainly very weird!

On another note, I personally do absolutely not trust btrfs due to its creator and very long time shaky lossy raid issues. Since there are enough performant and proven long time reliable filesystems available I use others.

Anyhow, getting to the point - I'd not entirely rule out something with btrfs as a separate issue too. I've just seen too many things that your ram issues could've been a few freak issues resulting in this.

Although I fully agree in your deduction!

100% consistent with static damage.

thats the thing about ESD damage - it can reduce reliability or operating margins. It rarely shows up as “whole part entirely nonworking”.

its mandatory if you don’t want to damage CMOS gates

yeah, just best ptactice. I've build 5 desktops over the years, never cared about static discharge, and only ever had a mobo fail after a 4-5 year lifespan