My bootloader has survived just fine despite being dual boot for the past 2 years. It may have something to do with me only having booted windows once in an that time (to fix a borked NTFS drive)
this post was submitted on 13 Jul 2026
248 points (97.7% liked)
Programmer Humor
32245 readers
1553 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 3 years ago
MODERATORS
That certainly helps.
In my case the solution is two EFI partitions.
Windows finds the first and doesn't bother looking for a second one, which happens to contain grub and my efistubs.
Windows will go ahead and clear the UEFI menu sometimes, but manually booting an efi file and then re-adding the grub and stub boot entries is small compared to having my stuff actually deleted.
Dual booting us viable, if you're curious its good to try linux via dual boot. Windows doesnt break the linux bootloader. The incident referencing was a bug I believe. I know plenty of people who've been dual booting for 2+ years keeping both OSs up to date with no issue.
I’ve had windows nuke my bootloader at least thrice. Stopped dual booting a few years ago so I’m free of that nonsense.
I have had Windows update completely obliterate my Linux partitions at least twice.
Do you remember if its happened in the past 2 years? A patch windows put out in 2024 is supposed to fix this.
I have had it break my bootloader when I was dual booting, if it wasn't my main pc then I might risk it but I'm not rolling the dice on if windows decides to break it again.
Still it's a really good idea to keep a rescue USB drive handy, for when windows decides to update it's boot loader and blitzes your setup
The reason I just overwrote the Windows partition, instead of futzing with fixing dual boot was GDID. MSFTs global ID that tracks, literally, everything you do.
If you bought a store laptop, I’d bet those configuration signatures were recorded when it got imaged… for the police of course.
"Linux supported hardware" is an outdated phrase only used in windows propaganda today.
Psht. I wish! This is wrong and will set people up for failure. There is absolutely hardware that will work well with Linux and hardware that will not.
I tend to run into problems with brand new laptops. Microphones don't work, web cams don't work, fingerprint readers don't work.
I have a Dell Dell Pro next to me with a web cam that doesn't work. Arch, btw.
I also have a Lenovo T14 where everything does work.
The point is you have to RESEARCH before you buy. Otherwise, you're gonna get mad a Linux for not supporting your hardware, instead of being mad at yourself for not researching first.
Hardware that's too old is problematic and hardware that's too new can be problematic.
Wait, it isn’t the point to nuke “spy equipment” with a new OS?
And unsurprisingly my framework laptop works perfectly under Linux
Absolutely not.
Signed, owner of half-supported hardware.
What Linux kernel are you running which isn't supporting your hardware?
Out of curiosity what hardware are you using that's not supported?
HP Reverb G2 for me. Still waiting on Monado to get it fully working but no such luck yet. Hugely appreciative to the dev team for all of their amazing work, of course.
Peripheral devices, mostly. I have some half-supported, like Logitech mouse (G-shift doesn't work), and for some I rely on open-source devs (like Corsair keyboard for certain keys/modes/connectivity fix). Sure, you can say just buy compatible devices, but it's not always viable to replace everything you owned before moving to Linux.
Certain fingerprint readers and touchscreens
ex. Goodix
It's not the fault of Linux, it's the hardware manufacturers. Still, you need to consider it before buying the device
Printers 🤣
In my experience, the only OS where printers won't have drivers is Windows.
But I don't deal often with dark demoniac systems, so there are probably lots of niche hellish devices that I don't know the details.
BS, I have gotten HP printers to work on Linux with no problems.
My Epson inkjet is a paperweight without w*ndows
I've got some LianLi case fans that aren't supported by anything Linux that I've been able to find. I run a barebones VM just to control their features.
What case are you using? I've got a LianLi Lancool 216. It's a little loud but it runs just fine for me.
Off the top of my head, my case is a LianLi O11, but I was talking about my case fans, which are... Oh lord, their naming is so obnoxious, the... TM LCDs I think?
lconnect just isn't linux friendly, which is kinda surprising. I've got the 8.8 universal screen, which I could just toggle into a second display and get all the system data that way when running under linux.
Unfortunately this is not true. If manufacturers do not support Linux, then it is up to dedicated community members to reverse engineer drivers. Much love to these amazing people ❤️
Things have gotten much better in recent years because now Linux is seen as a legitimate operating system and not just a platform for hobbyists.
There's still tons of devices where Linux doesn't work properly with them.
My Intel wireless cards cannot maintain a 6ghz wireless connection for shit despite some of them being over 5 years old. And Intel. Latest stuff, older kernels, none work well. Oddly whatever version of Fedora I had worked the best. My wifi wasn't unusable when 6ghz was an option. It only dropped to 5/2.4ghz once a minute instead of every 5-20 seconds.
For me any Wi-Fi drops were solved by disabling power saving in NetworkManager
Create a conf file:
sudo nano /etc/NetworkManager/conf.d/wifi-powersave.conf
Add this into the config file:
[connection]
wifi.powersave = 2
Then restart NetworkManager or reboot your system
My guess is that you are noticing the difference between new and old kernels
Sure, but that doesn't change that it's regressed since that one version and still hasn't been re fixed.
If the old (or LTS) version of the kernel doesn't support something newer, and the new version of the kernel does, that would not be a regression.
I learned this when Skylake first came out. Ubuntu LTS didn't work on it because it was an old kernel and this was new hardware. If you have new hardware, use a new kernel.
This Fedora version was a year+ ago. Even on 7.0 wifi is unusable on my machines if I have 6ghz enabled.
2 separate bootloader partitions. Grub launches the windows bootloader on a different partition so it isn't aware of anything other than itself. Then the 2nd bootloader actually launches windows. Don't try to share one partition or else windows will inevitably wind up clobbering the Linux loader.
This assumes windows is not maliciously checking for other bootloaders in order to fuck with them, which I'm not willing to give MS the benefit of the doubt on tbh.
Windows will know, its lik a cancer
Then Windows will fuck up the EFI entry itself. Easy to fix of course but a pain in the ass when you are just starting with Linux and have barely any idea other than reinstalling for the 10th time in a few weeks.
Grub refers to this as chainloading and I did it years ago successfully (though with windows 10). Everything has to be EFI boot so grub can see the windows bootloader.
My gaming PC dual boots Debian and Ubuntu
Kirk : I use a computer with an AI assistant and 1 gb of free ram. How about you?
Homer : I have a normal computer that lets me do what I want with my hardware.
If you are on a desktop, there is always the option of throwing a GT 1030 in the secondary pcie slot and jumping through the 100 hoops to get Looking Glass set up.
Windows can't fuck the bootloader if you lie about its HDD access.
Wonderful day!
It's apparently the third day (in a week!) I see people share their negative view on the booting being damaged by Windows...
Frankly, it's quite odd to see so many people having the issue when Windows or any other OS rewrites the bootloader...
It's sure possible to have it safe, so that even Windows won't rewrite during its update.
Though, I've been into Linux for more than 20 years now, I do have a machine that has Windows 10 installed alongside Linux, even if it's more frequent to boot Windows in a virtual machine nowadays.
The idea is to not share the location for the EFI files (in UEFI mode), but let the systems have their own keeping them fairly isolated, where Grub v2+ or another bootloader you prefer, load them all respectively, being located on a safer partition.
For example:
-
We have two storages (e.g., SSD):
/dev/sdaand/dev/sdb. -
Install Windows on
/dev/sdb(so it creates its own ESP); -
Install Linux on /dev/sda (so it creates its own ESP), with a normal/manual partitioning:
-/boot/(for Kernels I have 4 GiB+);
-/boot/efi/(commonly, from 128 to 512 MiB is enough);
- Here I normally also have a swap partition, and separate:/home/,/var/;
- Select Grub to be installed on the/dev/sda; -
Boot the Grub in
/dev/sda; -
Update Grub within Linux, so it finds the Windows EFI on another drive via its os-prober.
Here, I believe efibootmgr should show the existing EFI, or you could check it manually in /boot/efi after.
Windows should operate on its own ESP it created on its own storage, and don't overwrite the Grub.
At voila!
To additionally clarify, in my personal experience for many years on Linux, I usually tend to see (and are fond of, personally) having separate mounts for contextually different data, where one of the most adequate in frequent circles and duties is to separate the responsibility as, for example:
- Main system (root) -
/; - Kernel (
~4GiB) -/boot/; - EFI (
~128-512MiB) -/boot/efi/; - User personal -
/home/; - Variable -
/var/; - Swap;
- (Optional) System configuration -
/etc/; - (Optional) Temporary -
/tmp/;
It's also frequent to see the Logical Volume Manager (LVM) active, that may support a more fluent organization of hardware and logical devices. In this case, we might have all the above mounts, except 2 and 3, practically encrypted, too.
One of my current main machines have the following partitions (though no dual-boot on it):
sda 8:16 0 953.9G 0 disk
├─sda1 8:17 0 512M 0 part /boot/efi
├─sda2 8:18 0 4G 0 part /boot
├─sda3 8:19 0 32G 0 part [SWAP]
└─sda4 8:20 0 917.4G 0 part
└─luks-12341234-1234-1234-1234-123412341234 252:0 0 917.4G 0 crypt
├─vg_system-lv_var 252:1 0 400G 0 lvm /var
├─vg_system-lv_home 252:2 0 400G 0 lvm /home
└─vg_system-lv_root 252:3 0 117.4G 0 lvm /
If interested, please check the following:
- file-hierarchy (File system hierarchy overview... - Linux manual page...)
- Encrypting an entire system;
On Windows, if I am not mistaken (please correct me if wrong), the most frequent is to have at least two explicit partitions, in addition to the implicit primary 4 ones:
- EFI Boot Partition we mentioned above;
- Recovery Partition;
- Microsoft Reserved;
- Primary Windows.
For example:
- C:\ - System and automatically organized User personal files (desktop, documents, variable as AppData/ProgramData);
- D:\ - Manually installed programs and manually organized User personal files;
You can include a separate data partition to enable easier maintenance for situations where either the primary operating system is likely to be replaced, or when multiple operating systems exist on the same device, such as Windows 10 and Windows 7. When a device has multiple hard drives, a data partition may be stored on another drive.
For typical single-drive configurations, it's best that you not use a separate data partition. There are two main reasons:
- The partition may not automatically protect data that is stored outside the user profile folders. For example, a guest user might have access to files in an unprotected data partition.
- If you change the default location of the user profile folders to any volume other than the system volume, you cannot service your image, and the computer may not apply updates or fixes to the installation.Source (Hard drives and partitions - Windows Documentation...)
Oh! I would recommend KDE Partition Manger if you prefer GUI for partitioning.
It's likely worth to mention that KDE Partition Manger (project source) is likely one of the best out there I found (tried at least 11 a few years ago) for convenient GUI Luks2 and LVM support, if required.
Even if compared to some of the popular, where Gnome's, GParted, and QtParted resulted in either unsupported logic for Luks2 and LVM or did not complete the task successfully. These tools are still awesome for other tasks, I believe!
Though, perhaps likely as you I do prefer shell or TUI, being dived mostly in terminals/servers, and a script is always an option, of course. Not to mention that even with the GUI above, manual commands are normally eminent/imminent.
Related: https://wiki.t2linux.org/guides/windows#separate-the-efi-partition-after-linux-is-installed
For example:
We have two storages (e.g., SSD): /dev/sda and /dev/sdb. Install Windows on /dev/sdb (so it creates its own ESP); Install Linux on /dev/sda (so it creates its own ESP), with a normal/manual partitioning: - /boot/ (for Kernels I have 4 GiB+); - /boot/efi/ (commonly, from 128 to 512 MiB is enough); - Here I normally also have a swap partition, and separate: /home/, /var/; - Select Grub to be installed on the /dev/sda; Boot the Grub in /dev/sda; Update Grub within Linux, so it finds the Windows EFI on another drive via its os-prober.Here, I believe efibootmgr should show the existing EFI, or you could check it manually in /boot/efi after.
Windows should operate on its own ESP it created on its own storage, and don’t overwrite the Grub.
At voila!
Then Windows will fuck up your EFI entries. Which is not a big deal if you know what you are doing but a completely different story for the audience you are explicitly addressing here when you even explain how to check those entries in the first place.
Also you did not actually mention that fastboot needs to be disabled in Windows, thus a clueless person will not understand the random hardware errors on Linux caused by not properly initialized devices and will blame Linux.
(And let's not even talk about some of the really insane stuff like pre-installed Microsoft SecureBoot keys that brick you whole system when removed because idiotic OEMs signed their own hardware's EFI drivers with the keys already pre-installed just because they can...)
So no, it's not "quite odd to see so many people having the issue when Windows". That's what Windows is causing, often intentionally so. Is most of this easily fixable? Sure... But it's a very effective deterrent for many people, so they never reach the point where they understand and be able to fix that stuff.
Windows never touched the main EFI entry in my cases, even at updating it from 10 to 11, and I clarified it 3 times.
With a few Google queries we may find it mentioned, yet I've just found a weak one at this moment:
If you are booting with Windows, you should simply be aware of the problem, because you can easily overcome it by temporarily changing the type code of the non-Windows ESP(s) if you run into problems. Note that Windows will boot just fine on a disk with multiple ESPs; it's just the installer that chokes on such disks.
Some documentations found mentioned relatively similar:
The only Microsoft supported workaround for booting multiple installations of Windows in a uEFI environment is to use a dual boot configuration. This will make use of a single ESP and one MSR while still allowing the user to choose to boot to an installation on disk 1 or disk 2.