UEFI\Boot Shenanigans
Don't you just love how some things are not standardized? Or they should be, but they don't follow specs. And how sometimes you just look at the machine asking yourself how any of this works?
Here is some hardware black magic and the why...mostly just for the entertainment value.
EFI
I utilize a program on my home network called efibootmgr which comically enough is fairly hard to find solid documentation on. This is because my motherboards are all UEFI systems and sometimes I have to repair things with the CLI because the motherboard GUI does not do what I need to.
When used like I expect: Allows me to set the boot order and boot into an OS over ssh. I actually have a 3 boot system and this is how I select the operating system for that machine. The works by using the EFI vars filesystem on the Linux kernel.
Strange edge case: boot order randomly shifts after OS install\upgrade...fairly sure this is a hook somewhere from running a dual boot even though you can argue an update should not update the boot order. Requiring automation to restore the boot order after updates. Fun note, this is how you fix that: sudo efibootmgr --disk /dev/nvme1n1 --part 2 --create --label "PROXMOX" --loader /EFI/proxmox/grubx64.efi
Really strange edge case: drive if removed sometimes completely deletes all boot entries associated with that drive. Nothing like having to manually re-add the individual bootloader entries to reference the individual EFI files.
Custom kernels
When building a custom kernel it is extremely easy to fill up the entire EFI partition and effectively require resizing the partition which sometimes makes Windows non-bootable unless you repair the bootloader.
Bootloader
Not that strange...just something went wrong: Linux boot loader gone, reinstall the bootloader...Windows bootloader gone run bootrepair.
Wake on LAN
Strange things on consumer hardware: Some consumer hardware does not properly support Wake on Lan...meaning a smart plug really quickly begins to feel like a good idea. And some motherboards like older Macs do not support it at all.
Memory
Did you know you can use SODIMM memory in a desktop form factor? Did you know that it will probably not properly boot a second time without a CMOS reset...best conclusion I can come to is the timings produced during memory training differ from what a cold boot would be which makes a nonbootable system.
Note to self: Programmatically jump CMOS with an ESP8266
Hardware passthrough
Qemu is supposed to cleanly claim and unclaim the hardware device. However on some consumer hardware you can actually pass in hardware once which then cannot be passed through twice without a reboot. Other times you can get really strange behavior by not passing in the entire device (ex you forgot to pass in the audio capability on a GPU).