Ubiquity fails creating a correct Windows dualboot on EFI computers (grub-pc <-> grub-efi)

Bug #1050940 reported by YannUbuntu
104
This bug affects 21 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Currently, Ubiquity sometimes fails creating a correct Windows dualboot when:
- either it installs Ubuntu in EFI mode when Windows is installed in Legacy mode ( examples: Bug #908109 , Bug #959446 , Bug #956412
http://ubuntuforums.org/showthread.php?p=12238420#post12238420 )
- or it installs Ubuntu in Legacy (not-EFI) mode when Windows is installed in EFI mode. ( example: http://ubuntuforums.org/showpost.php?p=12246811&postcount=6 )

In order to create a correct dualboot, Ubiquity should always install Ubuntu in the same mode as Windows.

This could be done by choosing between grub-efi and grub-pc based on the presence of an existing ESP when performing a side-by-side install, instead of whether the cd is booted in efi mode or not.

*************** WORKAROUND: using Boot-Repair to convert Ubuntu in the same mode as Windows.
See https://help.ubuntu.com/community/UEFI

Tags: iso-testing
YannUbuntu (yannubuntu)
summary: - Ubiquity fails creating a correct Windows dualboot on EFI systems
+ Ubiquity fails creating a correct Windows dualboot on EFI computers
Revision history for this message
Launchpad Janitor (janitor) wrote : Re: Ubiquity fails creating a correct Windows dualboot on EFI computers

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubiquity (Ubuntu):
status: New → Confirmed
YannUbuntu (yannubuntu)
description: updated
description: updated
YannUbuntu (yannubuntu)
summary: Ubiquity fails creating a correct Windows dualboot on EFI computers
+ (wrong Ubuntu mode)
YannUbuntu (yannubuntu)
summary: Ubiquity fails creating a correct Windows dualboot on EFI computers
- (wrong Ubuntu mode)
+ (grub-pc <-> grub-efi)
Revision history for this message
YannUbuntu (yannubuntu) wrote :

Bug #998097 may be a duplicate.

YannUbuntu (yannubuntu)
description: updated
description: updated
YannUbuntu (yannubuntu)
description: updated
YannUbuntu (yannubuntu)
description: updated
Revision history for this message
YannUbuntu (yannubuntu) wrote :
YannUbuntu (yannubuntu)
description: updated
Revision history for this message
YannUbuntu (yannubuntu) wrote :

Following Steve comment #6 on Bug #1015211, here are my thoughts:

> It should be obvious that if the firmware booted the CD under UEFI, the firmware is UEFI and we should install grub-efi to the install disk too.

You forget that the fact that many UEFI firmwares can boot on the CD/USB in a different mode than on the HDD. I added some examples in https://help.ubuntu.com/community/UEFI#Setup_the_BIOS_in_EFI_or_Legacy_mode
So if the liveCD/USB is booted in UEFI mode (= /sys/firmware/efi exists when running Ubiquity), it does not always imply that the UEFI firmware is setup to boot the HDD in UEFI mode.
Among the Boot-Repair users, I saw some Windows installed in Legacy mode (UEFI is setup to boot the HDD in Legacy mode), but when the BootInfo report (created when booting the Ubuntu CD) showed that there was a /sys/firmware/efi folder (so the firmware was booting the CD in UEFI mode).
Eg, such situations can result from the fact that some UEFI firmware try to boot the HDD in UEFI mode by default, but if there is no EFI file it then tries to boot in Legacy(mbr) mode.
These are not "buggy firmwares".

> we could rearchitect the grub packages so that we are always installing both grub-efi and grub-pc on all installs

This is a good idea, but IMHO not for all cases, let me explain:
The difficulty we have is that when installing Ubuntu (= when we are in live session), we can't know if the firmware is setup to boot the HDD in UEFI or in Legacy mode.
However, we know that:
1) if there is an ESP with Windows EFI file, and no Legacy Windows boot files (bootmgr+boot/BCD), the firmware is setup to boot the HDD in UEFI mode, so Ubiquity must install grub-efi
2) if there is an ESP without Windows EFI file, and Legacy Windows boot files (bootmgr+boot/BCD), the firmware is setup to boot the HDD in Legacy mode, so Ubiquity has to install grub-pc.
3) if there is an ESP with Windows EFI file, and Legacy Windows boot files (bootmgr+boot/BCD), the firmware is probably setup to boot the HDD in UEFI mode, so Ubiquity must install grub-efi. But here i think Ubiquity should also install grub-pc by security, in case the firmware is setup to boot in Legacy mode.

Hope this helps making Ubiquity better.

Revision history for this message
Steve Langasek (vorlon) wrote :

> You forget that the fact that many UEFI firmwares can
> boot on the CD/USB in a different mode than on the HDD.

No, I don't forget that at all; I assert that it is a stupid firmware design that makes it nearly impossible for an OS vendor to do the right thing when installing to the hard drive.

Revision history for this message
Steve Langasek (vorlon) wrote :

And BTW, any firmware that provides such a boot menu is certainly not compliant with the Windows 8 certification requirements, which require that when Secure Boot is enabled, only signed UEFI applications are executed. Booting anything using BIOS mode when SB is enabled is expressly forbidden.

Revision history for this message
YannUbuntu (yannubuntu) wrote :

> it is a stupid firmware design

I agree. Now, let's make Ubiquity more clever ;)

Revision history for this message
YannUbuntu (yannubuntu) wrote :

What about always installing both grub-pc AND grub-efi ?

(of course grub-pc only if there is no ESP)

Revision history for this message
Phillip Susi (psusi) wrote :

Installing both won't help since grub-efi can't chain load bios booting Windows. There's really nothing we can do to work around this insanity. You just need to decide if you are going to use uefi or not, and stick with that decision.

Changed in ubiquity (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
DaveC (dcrooke) wrote :

I disagree pretty strongly with the INVALID resolution. One of the key features of Ubuntu is ease of installation, and it fails without warning in this case. That's a bug.

One thing I don't grok is why 32-bit worked and 64-bit did not (it is a 64-bit CPU, and the 64-bit CD booted fine, but GRUB choked).

At minimum I'd suggest a pop-up saying "hey, this install may fail to boot, use 32-bit" or similar. I don't know how hard it is to figure that out. Alternatively, provide some help and a workaround, e.g. a menu option in the installer to manually select the correct boot setup.

Revision history for this message
Phillip Susi (psusi) wrote :

The 32 bit cd works because it doesn't support UEFI. Booting the 64 bit cd works as long as you do so in bios mode.

I suppose Ubiquity could switch back to bios grub when doing a side-by-side install, and there's no ESP, even though you have booted the cd in EFI mode.

Changed in ubiquity (Ubuntu):
importance: Undecided → Medium
status: Invalid → Triaged
description: updated
Revision history for this message
YannUbuntu (yannubuntu) wrote :

Phillip, your suggestion:

"This could be done by choosing between grub-efi and grub-pc based on the presence of an existing ESP when performing a side-by-side install, instead of whether the cd is booted in efi mode or not."

is a very good solution. I hope you can implement it for 14.04.

Best wishes for 2014 !

Revision history for this message
Erick Brunzell (lbsolost) wrote :

I assume that's what happened to me while performing my first UEFI Win 8.1 + Ubuntu GNOME dual-boot during 14.04.2 iso-testing on this hardware:

Intel Motherboard: DB43LD
Intel Pentium Dual-Core CPU E5300 @ 2.60GHz
Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)
Intel Corporation 82801JD/DO (ICH10 Family) HD Audio Controller (rev 02)
00:19.0 Ethernet controller: Intel Corporation 82567LM-3 Gigabit Network Connection (rev 02)
2GB DDR2 RAM

You can read a more detailed hardware summary here:

http://paste.ubuntu.com/10035895/

Boot Repair did easily fix the problem, but before running Boot Repair I created a boot info summary:

http://paste.ubuntu.com/10048056/

And here's the boot info after repair:

http://paste.ubuntu.com/10048113/

If YannUbuntu is still reading this I'd appreciate knowing if I'm correct in my assumption. I'm just not tech savvy enough to know from reading the before and after boot info summaries what's up.

Thanks in advance.

Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1050940

tags: added: iso-testing
Revision history for this message
Steve Langasek (vorlon) wrote :

Erick, it would be helpful if you would attach relevant debug information as attachments in launchpad, rather than linking to pastebins.

Your "boot info summary" shows the following menu entry:

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows Boot Manager (on /dev/sda2)' --class windows --class os $menuentry_id_option 'osprober-efi-30D8-159A' {
 insmod part_gpt
 insmod fat
 set root='hd0,gpt2'
 if [ x$feature_platform_search_hint = xy ]; then
   search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 30D8-159A
 else
   search --no-floppy --fs-uuid --set=root 30D8-159A
 fi
 chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

The boot entry /after/ the boot repair seems to be identical:

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows Boot Manager (on /dev/sda2)' --class windows --class os $menuentry_id_option 'osprober-efi-30D8-159A' {
 insmod part_gpt
 insmod fat
 set root='hd0,gpt2'
 if [ x$feature_platform_search_hint = xy ]; then
   search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 30D8-159A
 else
   search --no-floppy --fs-uuid --set=root 30D8-159A
 fi
 chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

So how exactly did the boot fail for you before running the boot repair?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.