I'm pretty sure it's not the mainboard, as that's been running stable for the past 6 years. Before my unfortunate "upgrade" to Beowulf, the CPU I'd put in last month was also stable. Both are fairly old so should be supported in Linux. So, I'm suspecting a remnant of Beowulf config somewhere as I've re-installed ASCII again this morning, after I removed a number of no-longer used dot files/folders in my users home dir. So far it hasn't locked up on me. See how long that lasts.

Come to think of it, it could be related to power management and/or screensaver stuff instead. I have the screensaver turned off and the power management switched off to the maximum intent, but after a period of no user input (mouse, kb), the screen still blanks itself (which is probably inside the monitor). I need to look that up and see if I can counter this behaviour (IIRC there was a kernel option to disable it, not sure)

(PS: for those who want to look it up, the mainboard is a Gigabyte F2A88XM-D3H with BIOS version F8, CPU is an AMD APU: PRO A10-8750B, no separate discrete GPU)

Well, after one too many freeze up I ditched Beowulf, tried to get Funtoo to work (but a core package for Mate failed to configure repeatedly and consequently build) then late last night I took my ASCII USB stick and booted from it. Installed ASCII, but sadly, the random freezes are still there. It might be related to Firefox, may need to look into that.

So, not a happy chappy here, to say the least >:-{  I may try Mint, but that means [shudder] systemd :puke:

Well, for the 2nd time tonight Beowulf crashed. I was browsing while playing 2 local video files (via smplayer and vlc respectively) and it froze solid. No input, audio looped continuously, no response at all. Only a hard reset could solve the issue. This was on the Xen-enabled kernel. On ASCII, this scenario was perfectly fine and it could do this literally all day and never miss a beat. Now running the non-Xen kernel, see if that changes anything.

So far, Beowulf impresses me badly for all the wrong reasons

Yeah, I did that too now. Didn't solve all issues, I still can't load a module required for Qemu. As root:

# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# modprobe kvm-amd
modprobe: ERROR: could not insert 'kvm_amd': Operation not supported
# modprobe kvm_amd
modprobe: ERROR: could not insert 'kvm_amd': Operation not supported
# modprobe -c | grep kvm_amd
alias cpu:type:x86,ven*fam*mod*:feature:*00C2* kvm_amd

So, what next?

Regrettably, that wasn't an option during my upgrade.

So, what a difference a few days make. It turns out the problem was of my own making, typical PEBKAC! I'd forgotten to update the BIOS and the old version didn't support he 'new' APU. (insert facepalm smiley)

I hadn't installed the amd64-microcode package. So that's done now.

Meanwhile, I had another crash, while avoiding playing video files. During several failed boots the kernel hung on a message complaining about ECC memory signatures not present (it's non-ECC DDR3). I've now taken out 3 RAM sticks so now running on 1x 8CB. Playing mkv video finished fine, am mp4 crashed after a while (ca 4 min in). I've also removed the nVidia GPU, so now on the R7 APU.

Stress looks interesting, I'll install it and see what it can do.

Devuan doesn't use ppa's, it's an Ubuntu thing. Devuan is not based on Ubuntu (and never will be) so you'd need to add the repository to /etc/apt/sources.list manually.

Sudo is a typical Ubuntu-base prefix, on Debian and Devuan by default* you don't need sudo, just su and you have root permissions. Achieve the same on Ubuntu with

sudo su

Now skip the sudo prefix from the above commands.

*this depends on whether or not you've set a root password during installation. If you have, sudo is installed, but disabled for your user. (installed because other programs need it anyway). Technically, if you set a root pw, your regular user is not added to the /etc/sudoers file.

Does it include a patch package to undo the horrible change in su behaviour introduced in the 3.0 release?