You would still need to pass the GPU through to the VM, but this can eliminate the need to plug the GPU output into another device or use a dedicated monitor.

I have never used it, but I know it is pretty common.

This might be of use to you:

https://looking-glass.io/

You might still need a dummy hdmi/DP plug/adapter.

Boot issues on Linux are like most of the other problems Linux has, there is no standard way to do things, so people invent their own ways, and it results in the problems we see today. This doesn’t just apply to booting, it also particularly includes dns and network management. Combined with the fact that its a low level thing people don’t want to deal with, it gets left to rot. Few understand it leading it frustration.

Grub isn’t a simple tool because it’s not solving only simple problems. A simple situation would be booting a VM, where something like systemd-boot is probably preferred over grub since the heavy lifting should already be done by the host OS at that point.

Also, it’s not grub that is usually broken (grub did load after all…), it’s something else like a bad or botched update or something similar that breaks support for some hardware or the initramfs got messed up. I frequently encounter servers that suddenly stop booting and get stuck in either the initramfs or at grub, and selecting an older option usually gets me back into the os proper. Also, I have noticed it’s most often ubuntu that gets messed up while rhel and friends are much less likely to break. Breakage on arch is usually the result of specific user error, or some incompatibility was introduced.

In your case, the issue could have been (just guessing) a new kernel was installed, but the config tool might not have been run to create the new references. It’s not exactly grubs fault if the thing it was suppose to point to no longer exists. Simpler systems like arch do not have this problem at all since the kernel is always overwritten in-place, so the references are unlikely to ever get broken, but this is not without pretty annoying tradeoffs.

I didn’t think to check the number of patches, but as you can see, a lot of those patches have nothing to do with x86 specifically, and some relate to the scripts to implement or change behavior for their distro. If you check Arch, it has not nearly as many patches and still works fine. https://gitlab.archlinux.org/archlinux/packaging/packages/grub

You are correct that grub probably is the better part of an OS, but so are most other bootloaders that actually implement useful features (UKI IS linux, for example). systemd-boot implements few extra features like filesystems and lvm. On Linux, it’s not the end of the world since you can pack in much more stuff in the initramfs to support more filesystems and other interesting behaviors.

I can definitely agree that grub is not very actively maintained, and there are even some outstanding bugs and fairly important and reasonable feature requests that are sitting with ready to apply patches. But grub is also a mostly complete project. Most things boot fine with it as is, and it’s not like the EFI spec is constantly changing requiring regular updates. It’s also probably fair to say that working on grub probably isn’t a walk in the park due to how low level it is.

To be more clear on how I implemented my little scheme, neither grub or a script actually sync anything. I have two completely independent ESPs that are not synchronized automatically in any way. But because the grub EFI binary supports btrfs, it can just point to /boot in whatever btrfs filesystem which is where most of the configuration actually is. In this way, the dual ESPs are generated once and occasionally updated whenever I feel like, and /boot can continue to be managed by mainline scripts without any customization, such as mkconfig whatever initramfs build tool since the mirroring is completely transparent.

It simply is not possible to replicate this without grub since no other bootloader (to my knowledge) supports btrfs, or any other raid capable abstraction. You could get close by including additional scripts to ensure the appropriate configs and images are synced, but that is another point of failure.

Primary issue I found with that software is there is no way to bypass certificate and old issues.

GRUB is still the standard bootloader in physical deployments because it is the most likely to work and supports most of the features you might want in a bootloader.

UKI based booting is interesting since it seems like it might support even more features. But the last time I tried to test it, there wasn’t a ton of documentation on it and the software still seemed a bit green and inflexible.

For example, my main computer right now has a completely redundant boot process. I have 2 disks which each have an efi system partition. And the root file system is btrfs raid1 across 4 disks. This was very easy to set up and completely supported by grub with no custom configuration needed. The only slightly tricky thing I had to do to install the second efi was to use an extra flag.