@greyknight33 bummer, I've never had that kind of trouble but maybe your host just isn't up to the task or something. well at least you maybe learned a few new things for next time :)
@RichardJohnson I've been to Thailand for a thing, the thing was a wedding - of a friend, not my own. hot and kind of a dump, lots of weird and creepy old white people, dudes especially. food is meh. the locals were pretty cool peeps tho.
@neanderthalsnavel its a stupid made-up term in general to trick people into thinking that "performing your contractually obligated and compensated amount of work" is some kind of strange outlier. when I first heard it I assumed it just meant doing practically nothing until they catch on and eventually fire you, but actually it means performing your job duties to the agreed upon required level.
I probably go above and beyond as I like my work and company, but I still find the term ridiculous
@greyknight33 you'll probably want to get spice working and read up on that if that's something you need, its not something I've ever been concerned with. the spice documentation does talk about PCI pass through and GL acceleration, so that may be worth looking into https://www.spice-space.org/spice-user-manual.html
@greyknight33 that should take care of 99% of the average user's use case. you can worry about learning the trickier parts of managing things with virsh later, if you ever even need to. also, if it didn't install it by default make sure you get the spice support enabled (usually its a separate optional qemu package), it improves UI responsiveness pretty considerably compared to VNC
@greyknight33 everything should be in your distro repositories. KVM is built into the kernel, so you likely already have that. what you need now is a VM manager and client. virsh is the default TUI manager, but it's more for headless applications. take a look at virt-manager, its a pretty clean GUI one that I think relies on QEMU for the client. So if you can find virt-manager in your repos, it should pull in most of what you need
@greyknight33 that question is getting a bit outside of my wheelhouse. I actually seldom need to use VMs at all these days, I haven't needed to use windows personally in about 25 years, or professionally in about 15. these days in the once per quarter off chance I need to run our front end software I just hop on our terminal services server. back when we didn't have that though I would usually restrict the VM to the minimum resources windows required, because it was a waste, to me 🙃
@greyknight33 for something like this, unless you really need the bare metal performance (meaning you're just pirating games), I'd just do it in a VM. even better if the VM is hosted in Linux. KVM is quite good for performance. you can keep it quite isolated this way, just make sure you keep your VM software and drivers up on security updates. then ghosting a drive is as simple as making a backup copy of the raw disk image file.
@greyknight33 there's very few Linux viruses, they could easily be made but nobody does because they're targetting the biggest easy target. that said, just because windows doesn't know how to read your Linux partition and pretends it isn't there doesn't mean its safe from a virus targeting it. you could easily implement the filesystem in user space in the virus and write directly to the disk without windows filesystem support. lots of DBs work with raw disks like this and their own "filesystems"
@greyknight33 I saw you posted another toot with more context saying it was an *external* separate ghosted drive? so as long as kept fully isolated from each other (e.g. not using the same USB thumb drive with both), most of the things I said wont be a risk. I was assuming 2 partitions or drives in the same machine. BIOS is still a possible but unlikely option, the real risk then is the network. its a ghosted image, so they're identically vulnerable to whatever caused the original compromise
@greyknight33 are the 2 disks/partitions each separately encrypted? if not, yes, easily. if they are, it could still be spending cycles on the infected install when running to break the encryption of the other. is secure boot enabled? if not, pretty easily via the bootloader, if it is, possibly still via the bootloader but it'd be trickier. otherwise the BIOS is an option but that's very manufacturer specific, so it'd usually be a last resort vector.
@AdamAtSea looks like a dependency problem on libs it needs in /usr/local/lib, check what's in there. Also you should be able to do "nm curl.so" to see the status of the libs it needs, check if any are listed as missing