Being able to choose the OS and kernel is also important. I would not want my hypervisor machine to load GPU kernel modules, especially not on an older LTS kernel (which often don’t support the latest hardware). Passing the GPU to a VM ensures stability of the host machine, with the flexibility to choose whatever kernel I need for specific hardware. This alongside running entirely different OSes (like *BSD, Windows :(, etc) is pretty useful for some services.
Same here, though more out of lack of control over the host. Libvirt works on basically any distro, and you can easily configure whatever Linux distro you like best for running it. I can’t configure my boot process the way I want on Proxmox (at least not without learning/sidestepping its “convenience” tools/setup).
Looking at this, I’d personally delete both EFI and boot partitions, then remake them with the EFI partition significantly smaller (it should not exceed >100MB used). I have no idea what issues this would cause on Debian, and what specific configuration needs to be changed/updated. I’d guess you need to change the fstab entries, remake the initrds, and reinstall/reconfigure the bootloader.
Any manual messing with partitions, especially rootfs/boot/efi, can easily lead to a broken system. The fix will not be a simple procedure.
As you’re considering messing with your rootfs, I’m going to assume you have a backup. It’ll be significantly easier for you to wipe everything, install fresh new Debian, and copy your personal files over to the new installation.
If you’re this unsure about running potential malware in a VM, the best method is to just not run it at all.
You should be perfectly fine running with networking on your host, as long as you disable it in the VM configuration before running the potential malware.
It’s not. There’s no way to be 100% certain the shared folder daemon on the host has absolutely zero exploits, same thing for the networking stack used for transport. That also includes VM disk I/O, virtual graphics output, and any other communication between guest and host. It’d take some really advanced malware to abuse such exploits, but you’re better off minimizing attack surface as much as possible. That means disabling (or removing) every possible form of communication between host and guest, unless absolutely necessary for operation.
Start off with a clean slate. Windows, freshly installed from a Microsoft provided ISO (Assuming you’re looking at a Windows executable). Try to follow a guide on bypassing the MS account requirement (AtlasOS has a section of their guide telling you how to do this).
When you’re setting things up, there’s no restrictions to internet access, sharing, etc. You just have to be careful not to open/view the files you want to isolate, which is easy enough by for example putting the files in a password protected zip. You can also install any required tools now (like maybe 7zip).
At this stage, there’s a few options:
python3 -m http.server on your host. Then download it on the VM.When you’re ready to actually open the file, close off all access from the VM to the host. No networking, clipboard sharing, etc. Do this on the hosts VM settings, not inside the VM. Also note that without further tooling, it’s extemely difficult to tell if there’s any advanced malware present.
As soon as you view the potentially malicious files, consider anything coming from that VM as malicious. Don’t try to view/open files on your host, do not give it network access.
Malware can be (but often isn’t) incredibly advanced, and even an isolated VM isn’t a 100% guaranteed method of keeping it contained.
sudo systemctl status shows you what services are running, sudo systemctl list-units lists everything, including the services that failed. sudo systemctl status gdm.service shows you the status of one service in particular, and sudo journalctl -u gdm.service shows the output/logs of that service.
There’s a decent chance something is not starting due to misconfiguration. I’m guessing GDM based on previous comments. You can also check /var/log/pacman.log (make sure to save a copy, just in case), to see what packages changed/updated.
If you think it’s a pacman issue somehow, you can reinstall your entire system (excluding AUR or self-made PKGBUILDs). Note that this is almost never required to fix an issue. In a properly working system this “shouldn’t harm anything”, but nothing can be guaranteed on a broken system. The command for that is sudo pacman -S $(pacman -Qqn)
To answer the question in the title: No, because these systems inherently have different architecture. Something like OpenBSD (the OS) is relatively self-contained. Linux distributions have system components that are externally developed, but a user might rely upon.
What exactly is the “problem” you have with Linux package managers? It’s specifically extra complexity to separate “system” and “packages”. This works well for *BSDs that often develop the entire OS themselves, but would pose extra challenges for Linux distributions, where the line between “OS” and “user installed package” is much more blurred.