You do need a separate EFI, even though linux finds EFI, otherwise windows update trashes it randomly and why the meme we see here exists, with separate EFI windows doesn't know about it. You can shutdown windows mid update and boot linux, then reboot back to windows and update will continue. Siloed System
Not during typically reboots, but when some windows update or autofile repair happens it thinks it is the only OS on that partition and does what it likes.
Yes. When you install Linux it will auto detect the Windows EFI partition and put boot stuff there by default, but then windows comes along and will randomly trash that setup. So during install don't go with the suggested option, instead use the partitioning tool to creat another small EFI boot partition elswhere on disk, leaving Windows EFI and OS paetitions as is. Also create your root and home partition(s).
Install to those partitions, then Linux should prompt for Probe Foreign OS and add a chainloader entry to your grub menu. This entry, when selected, points grub to windows EFI partition ID and hands off the boot process to Windows. Windows is unaware it has been chainloaded.
As long as you set BIOS to load directly from the LINUX EFI entry then you will boot to Grub with Linux/Windows Dual option...But technically it is not a true Dual Boot, it is a sequential boot I guess.
I have had this for 7 years on same install and boot between W10 and Linux daily. Windows has never touched my Linux EFI.
For something like OpenSUSE you go into YAST2-GUI and click the probe foreign OS and then it asks you if you want Windows or Linux as the default boot. But to do it manually you add a menu entry to /boot/grub2/custom.cfg. or in /etc/grub.d/40_custom. After editing this you will have to run grub2-mkconfig -o /boot/grub2/grub.cfg which will compile all the grub info into /etc/grub2/grub.cfg
I believe the custom.cfg entries end up after the 40_custom entries that the OS may have included.
There is a persistent method entry if you did want to edit the /etc/grub2/grub.cfg directly, but probably not advised.
Here is my entry for Windows boot partition and location of MS boot. Also below that is a UEFI entry for geting back to the BIOS, not relevent to this topic, but just so you see how the menu entries are defined. In my system these are at the end of all the other Linux entries.
### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows Boot Manager (on /dev/nvme0n1p2)' --class windows --class os $menuentry_id_option 'osprober-efi-4E48-193F' {
insmod part_gpt
insmod fat
search --no-floppy --fs-uuid --set=root 4E48-193F
chainloader /efi/Microsoft/Boot/bootmgfw.efi
}
### END /etc/grub.d/30_os-prober ###
### BEGIN /etc/grub.d/30_uefi-firmware ###
menuentry 'UEFI Firmware Settings' $menuentry_id_option 'uefi-firmware' {
fwsetup
}
I responded how to via another comment, but wanted to mention that you may have a chainload to Windows already with your dual boot, but the main point was using two EFI partitions and chainloading to the other one, so Windows isn't ever in charge of files in your linux boot partition
i need to remove my windows boot drive from my workstation, but it lives in a rack. And has a temperament. Sometimes when losing power shit just refuses to boot for like an hour, eventually it randomly boots. Still unsure why. Could be anything really. Best guess is bad cmos battery though. Could be slightly bunged bios, could be marginally fucky cpu. Who knows. It's fine when shutdown with power for long periods of time though.
Gotta love modern hardware, if only 7 segment displays weren't a 300 dollar privilege.
For the rare occasion that I need Windows bare metal, I have a Windows 11 installation on a usb ssd originally installed via the Rufus Windows-To-Go option that I can just plug into the system and boot off it whenever I need it without it touching my uefi menu or partition on my internal drives. This way I can also use it on another machine if that need arises. Windows can even trim the usb drive it's running on. It pretty much works as if installed internally.
There was a time when Photoshop and other programs used a copy-protection scheme that overwrote parts of grub, causing the user not to be able to boot Linux or Windows.
They knew about it, and just DGAF. I don't remember their exact FAQ response, but it was something along the lines of "Photoshop is incompatible with GRUB. Don't dual boot if you use Photoshop."
Grub still has code for BIOS based installs that uses reed-solomon error correction at boot time to allow grub to continue to function even if parts of its core.img were clobbered by shitty copy protection schemes for Windows software.
Unfortunately, Linux can't run everything *yet. What do you propose people do instead when they can't access the apps they need to play with friends or work?
I haven't had to use any exam software recently, but in the past when I did I remember reading that it can detect when the host is virtual and will not run in a VM. Fortunately at the time I still had a windows laptop lying around, but I'd have a real problem if one of a courses now tried to do this.
If I dual boot windows, I tend to disconnect my Linux drive any time I do anything on the Windows side. Even installing Windows fresh using default settings, it managed to completely erase my Linux disk to put the Windows bootloader on it even though I selected a completely different disk for the Windows OS. Won't be making that mistake again. And by mistake I mean dual booting Windows. That pile of spaghetti code gets a VM.
I got used to windows overwriting the MBR and could generally work around that. But the last time I tried windows/Linux dual boot, it was windows that got caught in a recovery loop after a windows update. Linux was fine. I was impressed at how thoroughly Windows had killed itself on a basic unmolested install. At that point I decided I was done with windows on bare metal unless it was the only thing running. Windows goes in the virtual sandbox or plays by itself.
This is why you don't duel boot. If Windows can't play nice with others it doesn't get to exist at all. Proton+Steam means there is never a reason to run windows at all. "But I need some non-game windows applications." K. Proton is able to reliably run games in a library of tens of thousands of games with all kinds of bad programming and obscure hardware use. It's a standard for being able to run windows apps in linux that is going to cover any other application you have.
I have really been struggling to get proton to work in OpenSUSE, despite ProtonDB having only positive experience with the games I've attenpted. Running Tumbleweed X11 KDE with an 30 series Nvidia GPU. And in trying to fix them I seem to have broken my display drivers altogether. Plenty of system restarts, but all this happened without going into windows for a month. And that's why I dual boot 😢
I haven't run tumbleweed in a while, but I did have a similar issue on arch with X11 kde.
In the Nvidia settings, ensure that both Force Composition Pipeline and Force Full Composition Pipeline are disabled (unchecked) otherwise some games launched from steam using proton 8 or newer freezes on focus.
Obviously you'd have to fix your display drivers first. Maybe a reinstall is the quickest solution there.
Yeah, trying a Snapper restore since I'm out of things I know to look at, but that appears to be the next step. Thanks for the info on the Nvidia settings, is that in some config file?
There's definitely software that uses parts of the windows API that games don't touch. And doesn't work properly on Wine. I keep a windows install around just for using an analysis software for some lab equipment that refuses to start in wine.
Things like CAD software are also a struggle, though the latest wine seems to have resolved a number of graphics issues with getting PTC Creo to properly use the nvapi and nvidia graphics drivers through wine.
While wine is amazing, plenty of things don't work with it. Usually you don't need them, but if you do, you do
I'm using EFISTUB instead of a boot loader (on the PC running Arch, anyway) and Windows hasn't figured out how to break that, yet.
Somehow it hasn't figured out how to ruin my systemd-boot bootloader on EFI, (NixOS, this time) either. Perhaps it just has better support for EFI than BIOS?
