Advice on dual-booting Windows 7 with UEFI motherboard

Question

I'm going to build a desktop PC tomorrow, having finally purchased all the parts for it. I'll be installing Arch as my main OS, and Windows for gaming. However I'm not really versed in UEFI and its uses, advantages/disadvantages; since my laptop just uses BIOS.
My plan is to have 3 drives: 32GB SSD for the / partition, 1TB HDD for /home, and 500GB for Windows 7 x64 Ultimate.
Being unused to UEFI I was thinking about trying to just run everything in BIOS/Legacy mode, but that doesn't seem very sensible to me, especially since I have the hardware so I might as well use it.
So, reading the wiki and forums have led me to conclude that having a 1GB EFI System Partition on the SSD should be sufficient, and use gummiboot for my bootloader.
Other reading about setting up dual boots suggests to me that installing Windows 7 on its own HDD with MBR partitioning and Arch on a separate (set of) drive(s) with GPT partitioning will be sufficient. The reason being that if the BIOS is set up to boot sda, which has GRUB as its bootloader, using GRUB I can choose to boot into Windows despite it being on a separate hard drive.
My questions are (and it occurs to me that I am in the most part just looking to have my ideas confirmed):
1. Have I gotten this all completely wrong?
2. If I'm correct, can the above system of using GRUB on one drive to boot up an OS on another drive be applied to UEFI?
3. Has anybody tried/succeeded/failed to dual-boot in this fashion before me, and if so what did they do?
Thanks one and all! Hopefully I've made myself clear enough here

Answer 1

billodwyer wrote:Being unused to UEFI I was thinking about trying to just run everything in BIOS/Legacy mode, but that doesn't seem very sensible to me, especially since I have the hardware so I might as well use it.
Using BIOS/CSM/legacy mode can work fine; however, it will probably slow down the boot process by a few seconds, and it will close off some possible future (and even current) advantages, as EFI support in Linux is improved.
So, reading the wiki and forums have led me to conclude that having a 1GB EFI System Partition on the SSD should be sufficient, and use gummiboot for my bootloader.
A 1GB ESP is more than sufficient. In terms of space requirements, 100-500MB is enough, depending on how you use the ESP; but various bugs and default settings make me recommend 550MiB as a good size. Bigger is OK, but wastes some disk space.
A bigger issue is that the ESP won't really benefit much from being on your SSD, since it's read once at boot time. The biggest advantage to putting the ESP on the SSD in your setup is that if you use gummiboot, you'll also have to put the Linux kernel and initrd file on the ESP, so having them on an SSD will speed up the boot process by about 1-5 seconds. Overall, I'd probably put the ESP on one of the spinning disks.
One more comment: gummiboot can launch boot loaders from its own partition but not from other partitions. This can work fine if you plan things carefully, but with three disks and two OSes, you must be absolutely positive that Windows uses the ESP on which gummiboot is installed. I'm not an expert on Windows installation, so I can't offer any specific pointers or caveats on this. If you need something with more flexibility, both rEFInd and GRUB can redirect the boot process to other partitions or physical disks. rEFInd can also redirect from an EFI-mode boot to a BIOS/CSM/legacy-mode boot. (See below.) Overall, rEFInd's flexibility on this score is a plus compared to gummiboot; but gummiboot is covered in the Arch wiki's beginner's guide, which is a plus. You'll have to pick which advantage you prefer. (Note that I'm rEFInd's maintainer, so I'm not unbiased.)
Other reading about setting up dual boots suggests to me that installing Windows 7 on its own HDD with MBR partitioning and Arch on a separate (set of) drive(s) with GPT partitioning will be sufficient. The reason being that if the BIOS is set up to boot sda, which has GRUB as its bootloader, using GRUB I can choose to boot into Windows despite it being on a separate hard drive.
This is an unworkable idea, at least as stated and if you want to do an EFI-mode boot. Windows ties the partition table type to the boot mode: Windows boots from MBR disks only in BIOS mode, and from GPT disks only in EFI mode. Thus, using MBR for the Windows disk will require a BIOS/CSM/legacy-mode installation of Windows. Furthermore, neither gummiboot nor GRUB can redirect from EFI mode to BIOS mode (or vice-versa), so if you do it this way, you'll be forcing yourself to boot Linux in BIOS mode, to switch between BIOS-mode and EFI-mode boots at the firmware level (which isn't always easily controlled), or to use rEFInd to redirect from an EFI-mode boot to a BIOS-mode Windows boot.
Overall, you're best off either using GPT for all your disks and booting all your OSes in EFI mode or using MBR for Windows (and perhaps all your disks) and using BIOS-mode booting for all your OSes.
Under EFI, the boot process is controlled by settings in the NVRAM, which you can adjust with "efibootmgr" in Linux, "bcfg" in an EFI shell, or "bcdedit" in Windows. (The Arch wiki covers the basics at least efibootmgr and bcfg.) In a typical dual-boot setup, you tell the computer to launch your preferred boot manager (EFI-mode GRUB, rEFInd, or gummiboot, most commonly), which then controls the boot process. You set up boot loaders for all your OSes on one or more ESPs. (Note: A boot manager lets you choose which boot loader to run, and a boot loader loads the kernel into memory. GRUB is both a boot manager and a boot loader. rEFInd and gummiboot are both boot managers. The EFI stub loader, ELILO, and the EFI version of SYSLINUX are all boot loaders but not boot managers. Most EFIs include their own boot manager, but it's usually primitive and awkward to use. It's also not standardized, so my computer's built-in boot manager is likely to be different from yours. Thus, I recommend against relying on the built-in boot manager for anything but launching your preferred boot manager.) Thus, the lowest-common-denominator type of setup is to put your preferred boot manager, the Windows boot loader, and a Linux boot loader (which could mean your Linux kernel) on a single ESP. If you want to use multiple ESPs or otherwise split things up, you cannot use gummiboot as the boot manager, since it can't redirect the boot process from one partition to another. (Many EFIs can do this with their own built-in boot managers, but this isn't guaranteed, and it's usually more awkward than using rEFInd or GRUB.)
I know this can be a lot to absorb. The official rules aren't really all that complex, but different EFIs interpret the rules differently, and the different capabilities of the various boot managers and boot loaders creates a lot of subtle implications for how you set everything up.
1. Have I gotten this all completely wrong?
Significant parts of it, I'm afraid; see above. You're working under BIOS assumptions, which don't apply to EFI.
2. If I'm correct, can the above system of using GRUB on one drive to boot up an OS on another drive be applied to UEFI?
GRUB can do this, but gummiboot can't. You set one of those (or something else, like rEFInd) as your primary boot manager. Using both GRUB and gummiboot adds unnecessary complexity, IMHO. OTOH, setting up multiple boot managers or boot loaders is possible, and can give you a fallback in case one fails. For instance, there's a known bug that affects 3.7 and later kernels, mostly on Lenovo computers, that causes the EFI stub loader to fail sometimes. Thus, if you use rEFInd, gummiboot, or the EFI's own boot manager to launch the kernel via the EFI stub loader, having GRUB, ELILO, or SYSLINUX set up as a fallback can provide helpful insurance in case a kernel upgrade causes your normal boot process to fail.
3. Has anybody tried/succeeded/failed to dual-boot in this fashion before me, and if so what did they do?
Many people dual-boot Windows and Linux under EFI. There are a huge number of possible solutions. My own Windows/Linux dual-boot system uses:
rEFInd
rEFInd's EFI filesystem drivers
Linux kernels on Linux-native /boot partitions (two partitions, one for each of the two distributions installed on that computer)
The Windows boot loader on the ESP
This works well for me, but it wouldn't work with gummiboot instead of rEFInd, since gummiboot can't redirect the boot process to another partition. (gummiboot also can't automatically load filesystem drivers.) Arch Linux users who use gummiboot often mount the ESP at /boot, which enables gummiboot to easily launch the Linux kernel. Doing this with multiple Linux distributions would be awkward, though, since you'd end up with two distributions' kernels in the same directory.