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.

On the network issue:
Fire up aptitude, Synaptic or your package-manager-of-choice and search for this package:

firmware-iwlwifi

Also, install the package wpasupplicant (which probably will pull in said firmware package as a dependency) and let it finish installing. Then, see if your wifi shows up in the command:

ip addr list

The ip command is very important in networking. You can learn more about it by studying the man page for it:

man ip

HTH!

Do the following, as root;

mv /etc/apt/sources.list /etc/apt/sources.list.bak
nano /etc/apt/sources.list

Then copy these lines into the editor:

#deb cdrom:[Debian GNU/Linux 2.0.0-beta _Ascii_ - Official amd64 DVD Binary-1 20180213-18:54]/ ascii main non-free

deb http://pkgmaster.devuan.org/merged ascii main non-free contrib
deb-src http://pkgmaster.devuan.org/merged ascii main non-free contrib

# ascii-security, previously known as 'volatile'
deb http://pkgmaster.devuan.org/merged ascii-security main contrib non-free
deb-src http://pkgmaster.devuan.org/merged ascii-security main contrib non-free

Press Ctrl+o to save the file, then Ctrl+x to exit nano. After that, do:

apt-get update && apt-get dist-upgrade

This ensures you have an up-to-date system.

This sources.list file is actually mine   If you need the backports branch, add it manually later.