What you're proposing was somewhat common in the days of BIOS-only booting, and worked reasonably well in that context. There is a complication in EFI-mode booting, though: Under EFI, boot loaders are stored in the EFI System Partition (ESP) using semi-arbitrary filenames. To tell the computer what boot loader to use, boot loader filenames (including identification of the partition(s) on which they reside) are stored in NVRAM. The complication is that many EFIs will automatically delete NVRAM entries that point to files that don't exist. Thus, once you remove a disk from the computer, the EFI may delete references to its boot loader(s), and when you plug that disk back in, it will no longer be bootable -- at least, not without some way to restore its NVRAM entry.
I'd like to emphasize that not all EFIs do this; some leave invalid NVRAM entries in place, which means that they'll continue to work after you remove and then restore a hard disk. I'm not sure of the percentage of computers that remove NVRAM entries; you'll just have to check this for yourself.
One possible way around this issue is to make use of the "fallback filename," which is EFI/BOOT/bootx64.efi
(for x86-64/AMD64/x64 systems) on the ESP. The boot loader with this filename is launched if the firmware can't find any other valid boot loaders. Thus, you could copy or rename the OS's normal boot loader to this name to make it work; or you could put a boot manager in that place. (A boot manager lets you pick which OS to boot; a boot loader loads the OS kernel into memory. Some programs, like GRUB, do both things.) Something like my rEFInd boot manager might be helpful for this. In theory, putting rEFInd in the fallback position on both disks and clearing the NVRAM entries for Windows and Ubuntu should work fairly well, but there is one complication: Many EFIs treat the Windows boot loader (EFI/Microsoft/Boot/bootmgfw.efi
) as if it were another fallback filename. It may be promoted over the regular fallback filename, so the system may boot to Windows if the Windows disk is installed.
Note that, if the computer removes invalid NVRAM entries and so you rely on the fallback filename, booting may become unpredictable. That is, the computer might go to Windows one time and Linux another time, depending on what it had last booted, what disk(s) had been plugged in the last time it booted, etc. You should be able to use the computer's built-in boot manager to force a boot to a specific OS, but these tools are often awkward and are sometimes unreliable.
All of this makes the answer to the question of why you want to be able to remove disks important. Under EFI, leaving both your disks plugged in at all times is likely to be simpler than swapping them out, as you say you want to do. If you want to reduce the odds of one OS trashing the other's files, you might be better off with good backups and good planning of which partition(s) each OS is permitted to read and write.
Depending on your needs, an in-between option is to leave one disk permanently installed and place both OSes' boot loaders on that disk. You could then unplug the second disk on an as-needed basis. Be aware, though, that many distributions configure GRUB to rely on files in the Linux /boot
directory, so if you want to make the Linux disk unpluggable, you may need to put a /boot
partition on the permanently-installed disk. Alternatively, you could become an expert in GRUB so as to keep its configuration and support files on the ESP; or you could use something other than GRUB. As an extreme-case alternative, you could have a very small disk (even a USB flash drive) with an ESP and, if necessary, a /boot
partition, and use separate disks for the bulk of each OS's installation.
Another option is to rely on the Compatibility Support Module (CSM), which provides support for BIOS-mode (aka "legacy") booting. You could install both Windows and Linux in BIOS mode and boot the computer much like you'd have done ten years ago. Controlling the CSM requires some expertise, though; it's easy to accidentally boot in EFI mode rather than BIOS mode (or vice-versa), and if you're unfamiliar with it, you might not even realize what you've done until you've fully installed the OS and it ends up not booting the way you expected. See this page of mine for more on this subject.