Well, the online database for the Debian repositories says there is a powstatd for CyberPower UPses. But it doesn't show up when searching with aptitude. On the other hand, the xfce "power manager" is installed by default. It does pop up a message soon after booting about noticing my UPS and that it is charged, but that quickly disappears. How do I get a widget to stay on the task bar where I can check it? There doesn't seem to be anything in the power manager preferences, but there is something or other that keeps a status icon on the task bar in Mint.

Yeah, I found that in the repositories. But for some reason it's accessed through a metapackage named ups-monitor and simply putting that name on the command line causes aptitude to complain and refuse to install it. There are two packages, apcupsd and nut-client, and I have to "choose" one. Not sure what that means with a metapackage. Additional command line arguments?

After the freeze problem hit again, I realized I would have to try different hardware. The test system is ~12-year-old hardware. If not for the huge amount of kernel modifications for the Spectre and Meltdown panic, I bet it would still work fine. But things have changed and some hardware is just going obsolete.

The next system is "only" ~5-year-old hardware. A Haswell generation CPU on an Asus motherboard rather than the ancient nForce. Since it is a completely different system, there might be other problems. But I'll be watching for the video freeze problem and report if this occurs again. What concerns me is some of my other systems are older than this, though not as old as the first test system. I hope they are still compatible with all these kernel tweaks.

Interesting that the entire system does not lock up, though. It does seem to be the display that gets interfered with even if it is not specific to the graphical driver. I ran my test system for a few more hours today, and it had more freezes. Once I figure out where to enable compositing, it froze the entire display solid instead of just one window. And yet the streaming audio I was playing continued. But interaction was not possible, and I had to hit the "Big Red Switch" to recover control of the system.

Finally, I went back through the list of things I added when I installed. Only one of them is graphics related, and I thought it was only a set of command line utilities. "mesa-utils" is a package that I've been using since I first learned about Linux. But it's graphics related, and not essential anymore, so I removed it. The system then ran for several more hours with no detectable problems. Hmmm... Could there be a library conflict? The Linux version of DLL Hell? I'll have to run it a few more days to be sure.

Well, this is why I used a test system first.  It's a good way to learn that something sucks before getting to tangled up with it. It turns out the "tde-trinity" package used to install Trinity desktop is a meta package and does not allow uninstall. Aptitude just says it can't find the package. There is apparently no way to get rid of it other than a complete re-install of Devuan. Or maybe some sort of tedious search for all of the packages it pulls in and removing each one.

That leaves removing the nVidia drivers, which will be easier. And if that doesn't fix the problem I can go the full re-install route.

Edit: And things continue to get worse. The supposed command to remove the nVidia drivers doesn't work. Looks like it's re-install no matter what. Ugh... I guess I'll be trying an earlier version of the nVidia drivers after all this trouble.

Well, I thought it was clear that I was using the nVidia driver since I compared it to the nVidia problems in Windows. But anyway:

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK106 [GeForce GTX 660] [10de:11c0] (rev a1)
    Subsystem: ASUSTeK Computer Inc. GK106 [GeForce GTX 660] [1043:8422]
    Kernel driver in use: nvidia
    Kernel modules: nvidia

The other cards I have are of the same generation. Well, one other machine has a GTX960 but I don't want to go disassembling machines to swap parts around. That's a considerable risk of damaging things. I guess I might install Devuan to that other machine and see if similar problems occur. But I was hoping to work out the problems on this "test" machine before installing on my other machines.

From what I have been reading on Slashdot, they have far fewer vulnerabilities than Intel, but not none. Broadly, they tend to have a few of the "Spectre" problems, but nothing in the "Meltdown" category, which is mostly an Intel-specific problem. Quite a bit is riding on how secure this next generation of Intel processors turns out to be.

Wow, I am reluctant to use dd on a disk that has a working OS on it. Anyway, after going back and manually comparing the grub default on the new Devuan system with the one from the Mint system, I changed the parms to lower case. "saved" instead of "SAVED" and "true" instead of "TRUE". It seems to be working now. Odd that the control items are NAMED in upper case, but the parm apparently must be lower case to be recognized.

"grub-editenv list" produced no output at all. Even when run in a root terminal. From what I can see about grub-editenv in the man pages, that is where the default should be saved. But it's clearly not getting saved. This was a re-install over the previous Linux (Mint 17.3) -- could differences between the different versions of grub have caused a problem?

Well, that's an interesting thought. If the modprobe.conf commands are in fact not working at all, maybe I can just comment them out and let this user-space fail-safe do the loading? What confuses me is that the message "udevd[*number*]" is always so different. Isn't that number supposed to tell you something useful about where in the boot process the error occurred? Is it really failing at wildly different points every time? Where in the boot process would this other load system be invoked? I am not familiar with the Linux boot process at such a low-level of detail.

Well, it seemed to be the TDE widget, but when I removed network-manager-gnome it went away. Now I have re-installed network-manager-gnome and the little systray widget is in place. I'll not fuss about it anymore. That leaves the nvidia-driver spurious error message problem.