I thought I was safe from this if I installed windows on a completely separate harddrive... I clearly overestimated Microsoft's ability to make on operating system that does not act like literal malware. Oh well! I guess I'm 100% linux now.
You likely have secure boot and a Microsoft package key installed in UEFI. They likely did what they are supposed to do and removed the unsigned software.
You must either sign your own UEFI keys using the options in your bootloader that may or may not be present, or you must use a distro that has the m$ signed secure boot shim key. These are the only ways for both m$ and Linux to coexist. Indeed, with a shim key (Fedora/Ubuntu) you can easily have a windows partition on the same drive without issues.
Secure boot is a scheme to steal hardware ownership. Of course they say it is not because the standard specifies a mechanism to sign your own keys. However the standard specification is only a guideline and most consumer grade implementations do not allow custom key generation and signing.
If you need to do your own keys, search for the US defense department's guide on the subject. It is by far the most comprehensive explanation of the system and how to set it up correctly. They have a big motivation to prevent corporate data stalking type nonsense and make this kind of documentation accessible publicly.
If your bootloader does not allow custom keys, there is a little known tool called Keytool that allows you to boot directly into UEFI and supposedly change the keys regardless of the implemented utility in the bootloader. I have never tried this myself. The only documentation I have found was from Gentoo, but their documentation assumes a very high level of competence.
You can just turn off secure boot if you don't want to deal with using your own keys.
I would recommend the Arch guide rather than the DoD guide (it's a bit more hands-on). The software mentioned there may not be in less modern distros like Ubuntu yet, though.
Windows went a step further on my machine. I thought it had just screwed up my bootloader, but when I went to restore it my Linux partition was completely gone. Windows Update had deleted the partition.
How else would one motivate itself to learn about grub, boot partitions, UEFI, MBR and all the other wonderful crufty technologies involved in starting operating systems?
Is it just me or does no one actually know how any of it works, and everyone relies on a mixture of grub-install, os-prober, Boot Repair, bootcfg, and random internet guides to make it all work? I dual boot windows and linux and I don't understand where any of the boot files actually live or how they function. It feels like the deeper I dig, the more nondeterministic it all is.
I can think of three ways that this could've happened without either OS being broken necessarily.
One is that you're still on an MBR drive (maybe you upgraded from Windows 7?) which can only have one single bootloader. The drive you pick to install Windows' (or Linux's) files doesn't necessarily determine the location of the bootloader in that case. With MBR, both Windows and Linux are right to replace each other.
If you installed an UEFI system, this shouldn't happen. There is, however, some broken hardware that causes this problem. Instead of registering a bootloader into the system on a normal path (say /boot/efi/linux/grub.efi), it'll only boot the install medium/fallback bootloader EFI file. Both Windows and Linux put their bootloaders in the fallback location for these broken devices so they work. In this case both Windows and Linux are right to update these files and the problem lies with your broken motherboard. This usually happens with older computers.
There is another possibility. Microsoft got their Secure Boot key leaked over a year ago, and they've slowly been rolling out key updates so malware can't use their key to hijack Bitlocker and bypass Bitlocker. If your bootloader hasn't been updated to have the modern signing keys, and Microsoft renewed their keys, the motherboard may reject the bootloader. As far as I know there are new shims available, but with you speaking of reinstalling the bootloader to fix it, this may also have happened. A workaround would've been to disable secure boot, update the bootloader once the system has started, and turn secure boot on again, but Linux doesn't warn you about this problem.
Microsoft is right to revoke their long-leaked keys, and this is the whole reason keys can be updated in the first place. Unfortunately, good tooling for secure boot doesn't exist in Linux. In my opinion, the user should only deal with this issue once, during setup, and Linux should manage user keys for its kernel already instead of relying on the user executing a bunch of complicated commands. A combination of secure boot and an fTPM (hardware TPMs should be considered compromised at this point) have the ability to bring Windows-like security mechanisms to Linux, but so far no distro seems to bother.
It's also possible that your motherboard just got its bootloader config corrupted. Mine does that sometimes, it's a real pain. Grub does it, Windows does it, it'll just garble up the bootloader entries and fall back to the fallback bootloader which is a 50/50 chance of booting either OS, basically.
Not having to ever touch Windows again has made my life infinitely better.
I can handle setting it up for a buddy on their new PC I'll build. Getting to build a new PC is worth it. These fools don't even realize how much I enjoy building their PCs. They don't even charge me for it.
UEFI or legacy BIOS? I recently installed Windows 11 on a machine with Proxmox on NVME but installed Windows on a SATA SSD. Windows added its boot entry to the NVME SSD but did not get rid of the Proxmox boot entry.
I’ve definitely had the same issue as you on in the past on legacy BIOS and when I worked in a computer shop 2014-2015 we always removed any extra drives before installing Windows to avoid this issue (not like the other drives had an OS anyway).
It’s a gaming machine. I mainly use a gaming VM with GPU passthrough under Proxmox, but the anti-cheat is some games (Fortnite and The Finals) don’t allow you to run them in VMs. So I run those games in Windows directly under a standard user account as a compromise.
the partition was still there, but if i tried to boot from it would just kick me back to the bios. unless there's some obscure grub bug that happened to trigger exactly after i booted into windows i guess...
the fix was pretty simple, i just reinstalled grub from a live environment.
This happens often. There's a lot of documentation on line on this topic. You can probably fix it with a bootable Linux USB key, mount your Linux partition, chroot into it and run grub to reinstall it in your efi partition.
I always had trouble with running dual boot, mostly because I don't really have a clue about all this stuff. So the consequence was to ditch Windows. Never going back.