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.
It does that for some decades already. The trick for dual booting was always to install Linux second. :/
Go into your bios and change boot order.
as is tradition
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.EFI booting is pretty straightforward, and you can mount and browse the efi boot partition easily to see the actual executable files, and view the entries added to firmware to point to them with efibootmgr.
MBR booting was not so fun.
There are resources out there to learn exactly what’s going on, and the process is not too complex.
I’ve recovered a bunch of nuked MBR records and broken boot partitions myself, and maybe things UEFI added some complexity, but it’s not hard if you have a live USB ready and know the appropriate conjurations.
Most of the fun comes from self centered arrogant companies that make monocultural software, blatantly ignoring that other OSs may already be installed.
welcome to the club 😂
did it overwrite your GRUB partition or did it just remove the uefi entry?
iirc the later is pretty easy to fix with efibootmgr if you have a live cd / usb
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.
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.
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.
Great answer.
You can just chroot and fix the boot/efi partition. No need to re-install Linux completely.
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).
… may I ask what is your use case to install Wins alongside Proxmox (instead of in VM)?
In just curious & will prob learn something :).
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.
Ohh, interesting.
Also kinda dickish of them.
I kinda get it. The host has complete access to VM memory and can manipulate it without detection. Both of those games are free to play as well so cheating is more of an issue. I have no idea what Back4Blood’s justification would be though.
That said it’s a PITA and given the massive attack surface of Easy Anti Cheat it becomes easier to justify running in VMs where you can isolate things and use snapshots if there is ever a breach.
Welcome to the club :-) Microsoft, the true champion in overwriting boot loaders since 198…someth.ing TM ©
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.
fTPM (hardware TPMs should be considered compromised at this point)
Interesting. Could you elaborate on that?
Basically, they all seem to either communicate over plaintext or have bugs that make them effectively communicate over plaintext. I think https://www.secura.com/nl/blog/tpm-sniffing-attacks-against-non-bitlocker-targets has a nice, short overview of the problems. fTPMs have had their troubles but firmware updates can usually resolve those.
So far, all attacks can be fended off by setting up a secure TPM PIN, but after so many issues, I’m not confident in hardware TPMs anymore.
Thanks, much appreciated!
It’s worth noting that this isn’t a bug in the tpm uhh 1.1(?) specification. It’s working as intended.
The system was designed to prevent compromises from software attacks and people yanking the hard drives, not keep an enterprising uart-haver at bay.
State level attackers were never the target of the tpm and neither were downwardly mobile highly educated individuals.
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.
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.
Yeah, I didn’t risk dual booting. I have Windows 10 in a VM and a Windows 11 To Go USB drive.
This is why my machine straight boots into linux and if I want windows I need to use the BIOS boot selector
Run it in a VM
