Odd. I found this one:
http://cdn-fastly.deb.debian.org/debian … _amd64.deb

Did you update the package list?

Thx for the reply. I doubt the SD card was/is corrupted, as I mentioned the official Raspbian image worked fine on the same SD card. But it's encouraging you got it working, so I'll try again later (perhaps over the weekend). Thx!

Given the error and your info, I have a hunch therer's a mismatch between the UUID of the Devuan partition you used and the one reported in Grub. Obtain an 8 or 16GB USB stick and install Devuan on that (as sole OS), then try booting it. If that works, the problem is not Devuan but in Grub.

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.