If you need to ask how to break it, stick to the provided stable release, Kali in your case. Your question indicates you lack the knowledge to fix things when (not if!) they go belly-up

Note this is a Devuan support forum, not Kali (who have their own support channels).

You seem to be obsessed with "open source evarything', assuming because you "have reservations" about people trying to spy on you. That's fine, but if you're that paranoid about privacy, don't use a computer you haven't build from scratch yourself! Design your own hardware, using Open Source is quite easy: Kicad. Make your own PCB's, now that's a challenge if you know nowt about electronics. For chips, use un-programmed FPGA's. Not exactly open source, but as the specific chips in your system cannot be identified at the time of manufacturing, there's little risk you're targeted via this route (s'cuse the pun) Write your own bootloader, booting a plain, but patched (by yourself) Linux kernel. Next, create the entire ecosystem for your desktop, or rely on GNU/Hurd to port their software to your specific hardware. Not impossible, but quite unrealistic.

Maybe you should try being less paranoid about privacy, it's healthier too

PS: the suggestion to learn more about what certain phrases mean in FLOSS-land is highly recommended.

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.