I wonder how an AMD Ryzen-9 proc would fare

And I reckon now they're out (launched last week), the Ryzen-3 series will become dirt cheap. And TTBOMK (to the best of my knowledge) AMD doesn't suffer from Intel's security holes in their proc's.

Go wash your mouth with soap bleach you heretic!

Ah, ok, I see where you're coming from. Your quest could be summarized as "why does a UEFI boot partition have a short/small UUID whereas normal partitions don't." Right? I'm afraid I can't answer that, but you should be able to find it in the UEFI spec somewhere

From the image I see when it attempts to boot the guest, it fails to find LVM and subsequently fsck. This could be the result of incorrectly set permissions on the root-fs of the guest. I also notice, from your command, that the virtfs has a security_model as none, whereas fsdev has mapped. This might be the cause of the mismatch. (notice emphasis, I don't know enough about KVM to tell for sure)

man networkmanager

should tell you more, if it exists

If the eth1 port isn't connected to anything, then yes, it would wait for the timeout before proceeding the boot process. You may want to investigate /etc/network/interfaces to see if you can disable eth1 there. (I should too, as I too have a dual-ethernet port mainboard but haven't paid much attention to it as it's not in my main desktop )

As for nForce: it's reasonably well supported in the kernel because it exists for a fair while now: I bought my first nForce board way back in the mid 2000's.

It happens occasionally for me too (I install Devuan for my work, so I've done quite a few installs already ). Usually, restarting the installation process solves the issue, but sometimes another optical drive is needed. I'm still using the install media I made last year, so that shouldn't be an issue. (that is: aging disks or similar)  Most likely the source of the problem is a worn-out laser-diode in the drive, which is an age-thing too.

Just installed the earlier version (60.7.1) on Ascii. Didn't show up yesterday though.

Ah, ok. Thx for the explanation.

SD cards only have a limited number of read/write cycles due to the Flash memory they use. The Raspberry Pi Foundation has modified/optimized Raspbian to minimize this and thus don't suffer as much. Devuan isn't. Depending on your definition of "new" I'd suggest claiming it as a defective card from the manufacturer/supplier.

You, but it would also apply to the OP. Unless one is a dev, on package-based distro's, like Devuan, building/installing software directly from source is kinda defeating the purpose of a package manager and if the reasoning behind installing from source is obtaining an enhanced performance from the hardware used, you'd be better off with a distro that facilitates this much better then Devuan. But that's just my opinion, feel free to ignore it

There's a few, perhaps not immediately considered for the job:

LibrCAD
OpenSCAD
Meshlab

May not check all ticks, but it's a start.