- cross-posted to:
- linux@lemmy.ml
- cross-posted to:
- linux@lemmy.ml
This is a regular occurrence and honestly we need to stop recommending dual boot. Use separate drives if you need to, but sharing the same drive is destined to brick something
I literally got this error using a bootable SSD with Ubuntu Mate on it. Separate drives aren’t immune to the issue.
This isn’t true if you have a bootloader on each drive, which, I think, is what the we’re talking about.
I think I’ve managed to avoid this by making the Linux drive my boot drive and by leaving the Windows drive untouched. (i.e. grub bootloader on the Linux drive, with option to boot to Windows as the second choice)
I’ve got the same setup 😎
I don’t think dual boot has ever been a good solution (unless you also run one or both of the OS’s under the other in a VM).
Like, if you are unsure about linux, trying it out, learning, whatever, you can just boot a live"cd", or maybe install it on an external (flash) drive.
If you are kinda sure you want to switch, just nuke Windows; it’s easier to switch that way than to have everything on two systems, having to switch.
That is until you want to switch and use mostly linux, but you have friends who want to play one of those few games that only works on windows
The second windows isnt the only option for “all games without any effort”, it will be dead.
Well i believe it already is for the majority of games, though I don’t game anymore so I don’t know, proton wasnt 100% a year or two back
I recently moved from proton to a W11 KVM with my 4080 passed through.
Unfortunately those hostile GAAS probably would be able to detect and block you (I don’t play those games)
I’ve been on Steam+Proton for more than 3 years now. So many many games are now supported. It is usually the DRM kernel anti-cheats that are Windoxez only tend to be the broken ones. I dont buy or care about games that run anti-cheat in Windoze kernel.
But having 2 drives does not solve the boot loading issue, I mean, even if you have two drives, you still have only one bootloader, not?
You can have a own EFI partition per Drive (and on it whatever bootloader you want). You then need to use the UEFI boot menu if you want e.g. boot the Windows one. If you have 2 different OS on different drives they should never interfere with each other.
Well, i mean you could of course use the Linux Bootmanager to then forward to the Windows boot manager on the other disk. but i never experimented with that.
I just learned that you can do this setup even on one drive alone (having two bootloader on one drive in two partition and choosing in UEFI/Legacy BIOS)
even if you have two drives, you still have only one bootloader, not?
The idea is to have completely separate boot and OS drives. You select which one you want to boot through the BIOS boot selection (ie. pressing F10 or F11 at the BIOS screen).
This functionally makes each OS “unaware” of the other one.
Unfortunately it really doesn’t. And it’s actually Linux that’s the bigger problem: whenever it decides to updates GRUB it looks for OSes on all of your drives to make grub entries for them. It also doesn’t necessarily modify the version of grub on the booted drive.
Yes I’m sure there’s a way to manually configure everything perfectly but my goal is a setup where I don’t have to constantly manually fix things.
My install does not seem to do this. I removed the windows drive when installing Linux on a new drive. Put both drives in and select which one to boot in the bios. Its been that way for about a year and, so far, grub updates have never noticed the windows install nor added to grub.
That’s with bazzite, can’t speak for any other distro as that is the only dual-boot machine I own. Bazzite does mention they do not recommend traditional dual boot with the boot loader and recommend the bios method so maybe they have something changed to avoid that?
If you install each OS with it’s own drive as the boot device, then you won’t see this issue.
Unless you boot Windows via the grub boot menu. If you do that then Windows will see that drive as the boot device.
If you select the OS by using the BIOS boot selection then you won’t see this issue.
I was bitten by Windows doing exactly this almost 15 years ago. Since that day if I ever had a need for dual-boot (even if running different distros) each OS will get it’s own dedicated drive, and I select what I want to boot through the BBS (BIOS Boot Selection). It’s usually invoked with F10 or F11 (but could be a different key combo.
I did that and a Windows update nuked Linux from the BIOS boot loader a few weeks ago.
The only safe option is to have completely separate machines. Thankfully with the rise of ridiculously powerful minipcs that’s easier than ever.
Oh you sweet sweet summer boy…
We’re talking Microsoft here, they’ll make sure they’re aware and they’ll make sure to f you over because Microsoft
While I generally agree with that, that’s not what seems to be happening here. What seems to be happening is that anyone who boots Windows via grub is getting grub itself overwritten.
When you install Linux, boot loaders like grub generally are smart and try to be helpful by scanning all available OSes and provide a boot menu entry for those. This is generally to help new users who install a dual-boot system and help them not think that “Linux erased Windows” when they see the new grub boot loader.
When you boot Windows from grub, Windows treats the drive with grub (where it booted from) as the boot drive. But if you tell your BIOS to boot the Windows drive, then grub won’t be invoked and Windows will boot seeing it’s own drive as the boot drive.
This is mostly an assumption as this hasn’t happened to me and details are still a bit scarce.
No. You can have more than one EFI system partition with separate bootloaders on each drive and set their boot order in the BIOS, just like booting from USB or anything else.
This is also possible with just one drive. The efi boot entries for each OS are stored separately in the efi system partition.
EFI can also live in firmware memory.
You can pull the linux drive, boot from the windows drive, and if one of the firmware updates was for efi, windows will trash the entry for your Linux disk.
This has happened for me many times, I had to use a grub rescue disk to rebuild the efi table.
The boot entries live in firmware yes, efibootmgr can create and remove them. The are pointers to the bootloader. Many systems can boot from the disk itself without the entry, the entry just makes it pretty (“Fedora” instead of NVME1).
I’m not exactly sure what you’re suggesting. Isn’t that more or less what I just said?
Somewhat. One, a system can be bootable without the entries because they are just pointers to the actual bootloader, so even if windows does the stupid and deletes them it isn’t the end of the world. It does depend on your specific firmware though.
Also two, you can write them again with a single line in efibootmgr, they’re just saying “if I click Fedora load the shim from the EFI system partition on disk 1”.
This is very different than the old world where windows would delete your bootloader entirely and the MBR couldn’t be easily explored. They live in the efi system partition instead - or at least the shim does- and typically every OS leaves the other ones alone (even Windows, except in this case, although it didn’t touch the shim itself).
The initial comment was about the bootloader and really only applies to MBR partitions.
Removed by mod
Is there any issue with having windows on one drive and Linux on the other and toggling in the bios at boot? Do I introduce any problems by keeping my rarely used windows installation on a separate disk like this?
I’m not sure, but clearly something happens on the background, as my Debian drive broke after I changed it back and forth for the Windows drive. Grub fell back to rescue mode. After following some instructions and trying to boot from grub command line, Debian wouldn’t boot after it recognized the mouse. That’s what I know. Even in different drives, something happens on the PC when you go back and forth with Windows and Linux.
I should have been more clear,
Assuming dev/sda is Linux and dev/sdb is Windows, I have grub on sda and Windows bootloader on sdb. I use a hotkey at boot to tell the bios which drive to boot from.
Theoretically windows thinks it’s the only OS unless it’s scoping out that second hard disk.
It updates Secure Boot in the BIOS, so you could completely remove Windows but the Secure Boot update would still be in the BIOS and affect the boot loader.
Good intention, shit execution.
If Microsoft didn’t have a decades-long record of pulling shit like this, they might get the benefit of the doubt.
Never attribute to malice that which is adequately explained by stupidity
I hate this phrase.
A lot of the time, people (and especially monopolistic, tax-dodging, $3.2 trillion multinationals with a long history of anti-competitive behaviour) really are just cunts.
Time and time again, we see big companies doing anything they can to destroy competition, mislead customers, etc.
Never attribute to stupidity what can be adequately explained by malice.
It’s not like MS coined EEE or anything…
In business and politics “malice” and “stupidity/incompetence” are one and the same.
stupidity is a once-off
malice is a pattern
and even if it’s not malicious, a pattern of stupid action needs to be stopped just as much as malicious action
stupidity is a once-off
🎶 …this iiiiis my one an only wiiiiiiish! 🎶
Microsoft has been consistently “stupid” for a very long time about this one particular thing.
Stupidity doesn’t adequately explain the number of times they have done this. I’m surprised it’s even a headline anymore.
Never attribute to malice that which is adequately explained by stupidity
Emphasis mine. Incompetence on Microsoft’s part is not an adequate explanation for this latest action matching a pattern of other actions designed to antagonize FOSS users.
“wasn’t supposed to”
Are you quoting CroudStrike?
I’m quoting OP’s summary (or quote). I’m implying that Microsoft is hostile to Linux installations generally.
I guess I switch to single boot Fedora Silverblue just in time
Not the first time. I thought a Windows 10 update wiped grub, but Microsoft actually deleted my entire Linux partition. Others have experienced the same thing.
Windows is required for a couple of apps I need with no alternatives, but the only way it runs on any of my computers is in a VM.
I had the intention of reinstalling my windows because it was like from back when win10 was new and the winsxs folder was so big that a 100GB partition was not enough for just windows with all the 3rd party programs installed on another partition… but I noticed that all my games run on Linux so I ended up wiping the 100GB nvme windows partition and moving my dual boot Linux there. I’ve been without windows for a couple of months now and I haven’t really missed it.
I dual booted a few times back in the days of winxp and win7. Never had a good experience somehow windows or a grub update always messed up things. Haven’t ran windows in years but when I have to it goes on a separate drive now.
So they were trying to patch systems that use GRUB for Windows-only installs? What a load of BS. Why would anybody install GRUB to boot only Windows with that? Or am I overlooking something?
Furthermore, if GRUB has a security issue, they should’ve contributed a patch at the source instead of patching it themselves somehow. I’m a bit stunned at the audacity of touching unmounted filesystems in an OS patch. Good thing Windows still doesn’t include EXT4 and BTRFS drivers because they might start messing with unencrypted Linux system drives at this rate
In the mind of Microsoft, Windows is the only OS and all things on computers exist to facilitate Windows.
Grub has already been patched, that doesn’t mean distributions shipped it. SBAT broke systems that hadn’t been updated.
They updated the system key store to invalidate known vulnerable boot configurations. One of those configurations was old versions of Grub, which had a pre-boot exploit a couple of years ago.
The issue has already been patched for years, but it appears some Linux distros never bothered to update their system configuration. Not sure if this is a shortcoming of Grub or one of the distro maintainers that were affected, though.
In fact, Microsoft tried to not apply this patch on dual boot systems, leaving them vulnerable but working, but clearly their detection failed. I think their detection required chainloading the Windows bootloader or something?
Either way, the only Linux file that Windows will ever touch with updates is the “fallback for when the boot configuration is completely fucked” bootloader, which both Linux and Windows overwrite after installation, incase the boot configuration gets completely fucked. If you’re relying on that bootloader, you were always going to get fucked by some update eventually; either your installation failed or your motherboard is broken.
What is that latter fallback called? I set up my boot manually using an EFI stub last time I installed arch but wasn’t aware of any fallback bootloader
I don’t know what systemd-boot does, but the normal way to install a bootloader is to copy an efi file to the right folder (/EFI/archlinux/grubx64.efi or whatever) and register the bootloader in the boot configuration store. This allows you to pick the OS from a list by hitting the boot menu key for your device (f8/f12 usually I think?) rather than having to rely on something like systemd-boot or Grub to list all of your operating systems. This way, you can also boot UKIs and other Linux kernels compiled to simple EFI files, without ever even touching an independent bootloader.
As a fallback, both Windows and some Linux bootloaders copy their files to the /EFI/Boot/bootx64.efi directory. This makes the drive bootable in cases where the boot configuration store is broken, or if the drive wasn’t hooked up to the same motherboard when the installation was done. This is particularly important for installer drives, because you don’t want to add a boot entry to your motherboard for every installer you plug in.
The downside of this fallback file is that it’s just one single file in a preset directory, like the MBR of old. Some motherboards come with a file browser to select the EFI application you want to boot, but many will just give you a boot menu and nothing more. Because it’s a single file, that bootloader can either be Windows or it can be Linux. This isn’t a problem normally, but on broken motherboards this can render a system Windows-bootloader only or Linux-bootloader only. You can add both Linux and Windows to either, but the file being booted it always the last one that got updated.
There’s also a weird edge case for when you install Linux on a GPT disk from CSM mode, where the GPT disk will have an MBR. That makes the Linux system incapable of using any UEFI features and it has the same problem: if Windows puts its bootloader there, the drive will boot Windows.
As for bootloaders themselves, you generally only install one (though there’s nothing preventing you from installing both and having both be bootable, because they’re just entries in the UEFI menu!). If you want, you can install bootable Linux kernels as well, without any bootloader, though those don’t let you pick your boot options.
Thanks for the detailed explanation, makes a lot of sense! I guess what I did was set up a UEFI entry that specifies the location of the Linux kernel without any intermediate bootloader. Pretty sure I didn’t set the fallback, so I’m guessing that’s still owned by windows.
lol they fuck with my BIOS boot settings to the point i had to password it. they are that bad.
I agree they should have sent a patch to the grub source, but keep in mind big software companies like microsoft, Verizon, … do not allow software developers to send a patch or PR to open source projects. This is because in their contract it states that all code written on and during company times is owned by the company. This means that it is impossible for them to make a patch or PR because it would conflict with the projects licence and fact its open source.
Its a terrible thing, and it shouldnt be, but thats the fact of the world atm.
this changes nothing: microsoft should have sent a patch remains microsoft should have sent a patch; internal policies are irrelevant to actions effecting external projects
This means that it is impossible for them to make a patch or PR because it would conflict with the projects licence and fact its open source.
That’s not how it works. It just means the company owns the code for all intents and purposes, which also means that if they tell you that you can release it under a FOSS license / contribute to someone else’s project, you can absolutely do that (they effectively grant you the license to use “their” code that you wrote under a FOSS license somewhere else).
Not true. A lot of commonly known closed source companies contribute to open source software, including Linux and BSD
And not every team is allowed to do that.
Also, youre telling somebody who has worked with big companies not allowing it in their employer contract that he is lying? Riiiight…
A lot of google devs also are not allowed to do any linux work outside of work without explicit permissions. Development rights is an absolute mess, legally.
I usually dont care and do what is right, despite what my emploter contract says, but i have gotten in trouble for itThey can forbid you to work on opensource stuff while being in free time? I mean, I understand that you are not allowed to generate open code that utilises private know how of the company you work for. But not working on Linux in free time seems very strange to me 😮
Edit: There is a way: https://lemmy.world/comment/11915181
Yeah if you write proprietary code and then work on a similar project in your spare time, your company might sue you because you’re likely reusing code you’ve seen or written at work.
For example Windows developers are forbidden from working on ReactOS
Thats just dual booting. That wont work with the law if the contract says anything created using company hardware is theirs.
And yes, some companies need to give you a green light to work on projects in your free time, because they might have a team doing similar things somewhere, it might compete in something they would like to do in the future or like you said, might use company know how which is a huge nono. Its bs imo, but those clauses and rules are found in some employment agreements.
Remember, always read your employment agreements!
I’m not saying you’re lying, but you said
do not allow software developers to send a patch or PR to open source projects.
But this sentence in particular was misleading. Maybe you specifically did not have the right to do so, but in the Linux and BSD codebases there are a lot of @microsoft @netflix @oracle contributions, so at least there is someone in those companies authorized to do so
Fair, and ill edit my post accordingly!
There are teams that are allowed, and within those companies are teams that are directly related to foss projects because those companies are in the foundation or supports of the foundation. However, thats doesnt mean every (product) team in the company is allowed to or that they can do or change whatever they like. Its a complex mess
Thank you for have brought us your experience!
What? Microsoft have written and released and contributed to many open source projects - they created vscode for one. They are even one of the top contributors to the Linux kernel.
Yes, but not all devs within microsoft are allowed to work on non-ms foss projects. I assume wsl devs are allowed to send stuff to linux but visual studio devs probably are not.
The wrote and released VS Code - a completely opensource development environment. If they wanted to patch Grub I bet they could have found the permissions internally to do that. Microsoft is a lot more open to OSS contributions then they were in the past.
Not saying youre wrong, but you took the wrong project as an example hehe.
Visual code is not open source. Its core is, but visual code isnt. The difference is what visual code ships with, on top of its core.
Its like saying chrome == chromium ( it isnt ).Visual code comes with a lot of features, addins and other stuff that isnt in the core.
.net debugger for example, is not found in vscodium ( build of the vscode core ). And there is more stuff i cant think of now but have come across. Source: been using vscodium for a few months instead of vscodeSure, my bad. But it does not change my point. They have released stuff as opensource even if not all of it. Which means they can if they want to.
Doesn’t Windows break dual booting semi-regularly? I’ve always avoided it as I’ve had friends get burned by this in the past. I guess I just keep different OSes on different drives, but that obviously isn’t feasible for everyone.
I know that used to be the case. It’s why I stopped trying to use a dual-booting system and instead just installed windows in Virtualbox.
Yeah, it did get me to stop also a dual boot with Linux. I’m mostly Windows, so I’ve just used Linux in VMs.
It’s a lot better in uefi, MBR dual booting was always sort of hacky.
I have dualboot set-up on my MacBook and have no. But it is a long time ago, since I last started macOS and my Mac would not get new macOS updates anyway😂 that was the reason to install Linux in the first place 😝
Legit have never had an issue with multi boot and windows like ever, tbf I don’t go into windows that frequently anymore but it’s never given me grief in at least a decade. I know my experience isn’t universal though, so sorry to anyone who does have boot issues after windows updates.
In the worst case, could use bcdedit and use the windows boot loader (tbh I have no idea if that works here, but could be worth a try)
If you need to dual boot, be sure to use separate EFI partitions for windows and Linux, separate drives if possible. Windows has done this far too many times.
+1. I do this
Just remove Windows. One problem less on the list.
and unplug your linux drive when booting windows, just in case
Yess, let the hate flow through you! ⚡
No surprises there, just the usual shit
°-° /|-👍 / \
as they like to do every once in a while