[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

UEFI corner case we don't handle yet - dual-boot with non-UEFI Windows



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?

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
There's no sensation to compare with this
Suspended animation, A state of bliss


Reply to: