Gah...
Just ended up playing with Colin's thinkpad; he'd reported problems
with installation that sounded odd. Worked through it, and found a
hole in what we recognise and support during installation (and maybe
later).
We have a machine with both UEFI and BIOS-mode boot available, with an
existing BIOS-mode Windows installation (e.g. Windows 7 in this case)
*but* the machine is set up to try and boot UEFI first and *then* fall
back to BIOS (for some reason).
The existing Windows installation boots via the fallback, and the user
has no reason to ever investigate this. However, d-i will happily boot
in UEFI mode. When we get to partitioning, there is no EFI System
Partition (ESP), as Windows isn't using one. We then get to either of
two potentially bad cases:
(a) the user shuffles partitions around and makes an ESP, installs
the system OK including grub-efi. They then have a machine that
will boot via UEFI to grub, but maybe will not be able to boot
Windows. I've not tested this directly yet, but I can see this
happening. To get to their existing Windows installation, the
user will have to switch boot mode in the firmware setup - bad.
(b) the user does not make an ESP, installs a system but grub-efi
fails to install properly for that reason. I'm seeing bug reports
that suggest this path does *not* necessarily give a clear error
to the user, maybe in some cases no error at all. They reboot
their newly-installed system and find it immediately goes into
Windows with no sign of their new Debian installation at all.
How do we fix this? I think we need to find some way of detecting how
an existing Windows installation boots, *iff* the user is clearly
trying to set up a dual-boot system. If the existing Windows
installation is in BIOS-mode, we should *not* follow the UEFI path
through partitioning and bootloader installation; instead, we should
fall back to the existing generic/BIOS cases in various places. I
don't see this being *easy* to do, but there aren't many code paths to
worry about AFAIK.
What do people think?