How reliable dual booting has been for you?

Windows has consistently nuked my bootloaders and installed its own bootloaders on random drives. I gave up dualbooting years ago.

Haven't dual-booted in like 10 years, so I don't have hands-on experience with it, but AFAIK that's not really a problem since UEFI, or a much less common one.

Back then, with legacy BIOS computers, it booted by directly executing the first sector of the hard drive. This meant that there could only be one bootloader per disk, and so if Windows thought its bootloader was supposed to be used and it had an update, it just overwrote it. Or it would think it's been corrupted/infected.

Now with UEFI, it's its own partition and it supports having more than one there out of the box, so unless your boot process depends on detecting the default one rather than exactly which executable is the default, even if Windows updates it own as well as the default bootloader for a disk, it should be fine. Or at the very least it's so much easier to just go to the firmware setup and change it back without having to reinstall LILO/syslinux/GRUB.

I'm running Arch. My laptop (MSI GT76 Titan) has 3 nvme and 1 SATA drive connector. So I have the nvme set up for Linux and the SATA for windows because: why not?

I mainly use Windows for... nothing these days. I try to remember to boot to it to update it every couple months. But I haven't actually DONE anything in Windows in a while. I use Steam in Linux and play games there like Jedi Survivor, The Last of Us, Stray, Control, Hitman, ... without issue. No need for Windows for me.

I've found that the only way to dual boot reliably is to have windows installed on a separate, dedicated drive, and to keep all drives used by Linux air-gapped from the windows drive. Fast start and hibernate must also be disabled within windows to prevent it from putting hardware in an undefined state.

That being said, I haven't actually found any regular use for the windows install in years. mostly just keep it around as a sort of backup failsafe, or just in case there is a game that refuses to work in Linux. 99 times out of 100 it simply just collects dust.

Haven’t had a problem since I started using Linux full time in 2019 but I rarely boot to Windows (usually once every few months to update it). I have W10 and Kinoite (openSUSE before that) installed on separate SSDs. I used 2 EFI partitions (which I make backups of from time to time) on the respective drives the OSs are installed on.

No issues, as long as you have two separate drives. In worst case, you have to change your boot settings in UEFI, after a kernel update.

But I failed setting up Windows and Linux, both with drive encryption on one single SSD. I guess my failing prevented me from locking myself out of the system.

I use a lot of Windows, but I usually end up wiping the Windows partition to free space within six months, when I dual boot.

The performance is so much better on Linux on the same hardware, I just don't boot to Windows, unless it's the only OS that I have installed.

I've been dual booting Windows/Linux for 4 years on the same drive - no issues whatsoever.

I think as long as you use two separate boot EFI partitions, you're fine.

Ever since I switched to UEFI boot, Windows has never taken over the bootloader. With MBR, it happened all the damn time and was super annoying. I think as long as you're not relying on the default/fallback UEFI boot location you'll be fine.

A lot depends on the way the system is configured before Linux is started. You need to understand how secure boot is handled and the UEFI key system. This may be a deeper dive than you are interested in understanding.

The firmware on your motherboard is proprietary, and a major vulnerability. There is no guarantee of how well your UEFI bios system supports secure boot keys. In any case, there is a work around, but you're not going to like it. In order to avoid super complex user installations that require making and managing your own UEFI keys, or worse, using KeyTool to boot into the UEFI system, the large distro packagers have an option to apply for a 3rd party UEFI key issued by Microsoft. This key exists at the same level as the Windows key and is how most large distros are working on modern hardware.

The issue comes down to secure boot. Linux does not support Secure Boot directly at all. Maybe if the full UEFI SB standard was somehow required, perhaps it would be supported. The full standard includes complete user control over their hardware, aka full ownership. By not implementing the full standard, secure boot is used as a way to steal ownership and is nothing more than a bandaid patch for proprietary digital exploitation of the end consumer through planned obsolescence. The real fix would be requiring all firmware to be open source so that it can be effectively hardened, verified, and maintained by the community, but I digress.

If you run a system with secure boot disabled, and then boot into Windows, it may enable secure boot automatically. It is also possible for the OEM to issue a bootloader update and send your UEFI system an update directly (yes it has network access). This would make your unsecured Linux system invisible because secure boot would lock it out. I think recovery would depend on how grub2 is configured. It may get blacklisted or deleted for trying to access UEFI after SB is enabled like this. I'm not sure. I haven't had to deal with this and don't know what happens in this area exactly.

I can say that the whole Secure Boot/3rd party key thing uses a couple of apps that run before Linux, (at least on Fedora and I think all others with these keys). The apps are called lockdown and the shim. The shim jumps into the SB keys, slipping in under the Windows key. This enables lockdown. Lockdown is what ensures only kernel modules signed by the packager's key are allowed to run in Linux. Again, these apps are not part of Linux, but they are what makes installation much easier for the average person, and what keeps their system much more secure. This also makes problems, if for instance, you try to load an unsigned Nvidia binary kernel module (driver). This is why the kernel portion of the Nvidia driver was open sourced, and why the best distros like Fedora have a mechanism to update the kernel and automatically rebuild the Nvidia module from source while Secure Boot is running.

How well a distro will work with dual boot depends mostly on the quality of the software running long before Linux init. With Fedora, this system is called Anaconda (unrelated to python's container system of the same name). This system is the best I have come across. Indeed, the early support of UEFI secure boot is the main reason I switched to Fedora a few years ago.

Ultimately, it is this system that determines how well Linux can coexist with Windows. Prior to switching to Fedora I always kept 2 drives and never connected both at the same time. Now I have a disconnected copy of Windows on a drive, but run a single drive with both Fedora and Windows 11 on separate encrypted partitions. I never have a problem, but never actually use Windows. Windows is only used for some hardware settings like keyboard RGB. It is a stripped base W11 install, has no Microsoft account associated, has never seen the internet directly, and is completely blocked by my external whitelist firewall on my network, just like my UEFI system.

I don't recall Windows ever touching linux bootloader but I imagine it could if you had it scan & repair any potential boot problems. Installing any OS can result in bootloader being changed so I've always installed Windows first & then Linux, especially if only have a single drive. When dual booting with dedicated drive for each OS I install in the same order but I change the drive boot order in BIOS between installs as well. After installs are done I leave drive boot order so Linux bootloader is default. I can change the drive boot order if I ever have a need to use Windows bootloader.