Ubiquity installed grub-efi when it should have installed grub-pc

[martinr]

Goal:
Create a dual boot system with a pre installed Win7x64 and Ubuntu Desktop 12.04 LTS amd64 with Grub installed as the boot-loader in the MBR of sda.

Problem symptoms:
After Ubuntu installation from the Live CD along side Win7x64, Grub wont start at boot-up of the system. It boots straight into Win7.

Hypothesis:
The Ubuntu Desktop 12.04 amd64 Live CD, was booted with an UEFI boot sequence although the hard disk structure is MSDOS with MBR. This fools ubuquity into installing Grub in EFI mode and does not install grub-pc into the MBR.

For full information please view:
http://ubuntuforums.org/showthread.php?p=12030957#post12030957

[YannUbuntu (yannubuntu)]

Thanks Martin
(may be duplicate of Bug #916299 )

[Launchpad Janitor (janitor)]

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

[Steve Langasek (vorlon)]

Hi martinr,

> The Ubuntu Desktop 12.04 amd64 Live CD, was booted with an UEFI boot sequence
> although the hard disk structure is MSDOS with MBR.

If the machine was booted via UEFI, then installing grub-efi is the right thing to do.

Can you boot a liveCD in the affected machine and run 'efibootmgr --verbose', attaching the output to this bug?

[YannUbuntu (yannubuntu)]

Hi
after looking again at the forum thread, it appears that:
- the disk is Ms-Dos (not GPT)
- and Windows was installed in Legacy mode ( there is no EFI partition)

so Ubiquity should have installed grub-pc for sure.

Now my doubt is: did Ubiquity install grub-efi or grub-pc ?
(can anyone see this in the logs?)

(efibootmgr --verbose may not help, as the BIOS settings have been changed since the Ubuntu installation)

[Steve Langasek (vorlon)]

> - the disk is Ms-Dos (not GPT)

This is not relevant. UEFI does not require a GPT to boot; there is a specification for a declaration of EFI System Partitions on an MBR-only disk.

> - and Windows was installed in Legacy mode ( there is no EFI partition)

Also not relevant. To grub-installer, this just looks like a system that has an unbootable copy of Windows sitting on the disk.

Fundamentally, the problem here seems to be that the CD *is* booted in UEFI mode, but the firmware won't use UEFI when booting the OS from disk. That sounds like a firmware bug, and one I have no idea how to work around. 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.

It would be absolutely incorrect to blindly install grub-pc on systems that have clearly booted using EFI. Likewise, installing grub-pc instead of grub-efi based on the detection of non-EFI OS installs would trade one set of bugs for another. The only reliable fix here would be to know that this buggy firmware is in such an EFI-only-on-CD mode and install grub-pc in that case.

(Alternatively, we could rearchitect the grub packages so that we are always installing both grub-efi and grub-pc on all installs, something that I increasingly believe we need to be doing in order to support users across the BIOS->EFI threshold. But eventually we would want to drop grub-pc from EFI systems anyway, so this bug could still be a problem.)

[Steve Langasek (vorlon)]

It might be useful if someone affected by this bug could tar up /sys/firmware/efi from their system (while booted to CD) and attach it to this bug.

Leaving the bug 'incomplete' because we currently don't have enough information to try to address this.

[YannUbuntu (yannubuntu)]

> there is a specification for a declaration of EFI System Partitions on an MBR-only disk.

thank you Steve, i didn't know that. Please could you provide a link?

I will comment the rest on Bug #1050940 (as for the current bug we don't even know if Ubiquity installed grub-efi or grub-pc, so if the bug is valid or not).

[Steve Langasek (vorlon)]

On Mon, Oct 15, 2012 at 11:22:38PM -0000, YannUbuntu wrote:
> > there is a specification for a declaration of EFI System Partitions on
> > an MBR-only disk.

> thank you Steve, i didn't know that. Please could you provide a link?

UEFI Specification 2.3.1, section 5.2.1, Legacy Master Boot Record. (I
believe the spec requires free registration to access, so a direct link is
not possible.)

[martinr (martinr1111)]

I verified in the intial install logs (/var/install/syslog) that erroneously grub-efi was installed instead of grub-pc:

Code:
Jun 13 13:45:35 ubuntu grub-installer: info: architecture: amd64/efi
...
Jun 13 13:45:38 ubuntu grub-installer: Removing grub-pc ...
Jun 13 13:45:39 ubuntu grub-installer: Purging configuration files for grub-pc ...
Jun 13 13:45:40 ubuntu grub-installer: Removing grub-gfxpayload-lists ...
Jun 13 13:45:40 ubuntu grub-installer: Removing grub-pc-bin ...
...
Jun 13 13:45:44 ubuntu ubiquity: The following extra packages will be installed:
Jun 13 13:45:44 ubuntu ubiquity: efibootmgr grub-common grub-efi-amd64 grub-efi-amd64-bin grub2-common
...
Jun 13 13:45:57 ubuntu ubiquity: Setting up grub-efi (1.99-21ubuntu3.1) ...
...
Jun 13 13:45:58 ubuntu grub-installer: info: Installing grub on 'dummy'
Jun 13 13:45:58 ubuntu grub-installer: info: grub-install supports --no-floppy
Jun 13 13:45:58 ubuntu grub-installer: info: Running chroot /target grub-install --no-floppy --force
Jun 13 13:45:59 ubuntu grub-installer: Installation finished. No error reported.
Jun 13 13:45:59 ubuntu grub-installer: info: grub-install ran successfully

[martinr (martinr1111)]

The installation CD was booted in a UEFI sequence (default behavior). In my opinion the boot sequence for the installation CD should not lead to assumptions about the format of the system HD.

[Launchpad Janitor (janitor)]

[Expired for ubiquity (Ubuntu) because there has been no activity for 60 days.]

[YannUbuntu (yannubuntu)]

The problem is that Ubiquity chooses grub-pc or grub-efi according to the mode in which the install disk is booted, which is not always the mode in which the firware is set up to boot the HDD.

[Steve Langasek (vorlon)]

On Sat, Jan 12, 2013 at 04:03:11AM -0000, YannUbuntu wrote:
> The problem is that Ubiquity chooses grub-pc or grub-efi according to
> the mode in which the install disk is booted, which is not always the
> mode in which the firware is set up to boot the HDD.

This is pathological behavior on the part of the firmware. If the system is
configured in UEFI mode, it should prefer UEFI consistently for all devices,
not just for removable ones. The problem statement in this bug is incorrect
- ubiquity *should* install grub-efi when booted under UEFI.

The only reasonable way to address this problem would be to consistently
install both grub-pc and grub-efi on all amd64 systems, regardless of how
they're booted at install time.

[YannUbuntu (yannubuntu)]

> If the system is configured in UEFI mode, it should prefer UEFI consistently for all devices, not just for removable ones.

There is no such rule. Firmware makers can do what they want, including giving the possibility to boot the HDD in one mode, and boot the removable device in another mode.
See some examples here: https://help.ubuntu.com/community/UEFI#Set_up_the_BIOS_in_EFI_or_Legacy_mode

> The only reasonable way to address this problem would be to consistently install both grub-pc and grub-efi on all amd64 systems, regardless of how they're booted at install time.

I totally agree! (and this would also solve Bug #1050940 )

[martinr (martinr1111)]

Conclusion
When the Live CD is booted with an UEFI boot sequence, Grub erroneously expects a GPT structured HD, even if the boot HD is msdos/MBR structured. Grub doesn't installs itself to the MBR. When the same Live CD is booted with a non UEFI boot sequence Grub is automatically installed correctly in the MBR and Win7 is added too.

Discussion
Because more and more computers support UEFI nowadays, the out of the box installation of Grub and hence Ubuntu from the Live CD is expected to fail more often. I would suggest that the installation process should be updated to alert the user of a UEFI boot sequence conflicting with a non GPT structured target installation HD or better yet, if possible automatically make the correct Grub installation selection accordingly to the installation target HD's structure.

[Steve Langasek (vorlon)]

On Tue, Jan 15, 2013 at 01:48:53PM -0000, martinr wrote:

> When the Live CD is booted with an UEFI boot sequence, Grub erroneously
> expects a GPT structured HD,

Incorrect. UEFI does not require GPT.

> if possible automatically make the correct Grub installation selection
> accordingly to the installation target HD's structure.

This is wrong. The current on-disk layout tells you even *less* about how
the disk will be booted than the current boot method for the removable media
tells you.

[DavidEscott (david-escott)]

As a practical matter there really should be an override for the installer. I suspect Win7 will continue to exist for a number of years and with that there will continue to be UEFI systems that are configured to boot /dev/sda in bios mode but which will by default be configured to boot any other media it sees in EFI mode. Its really confusing to explain to someone that they have to go into their EFI firmware and fiddle with boot options to get the CD/USB keychain booting in bios mode.

My suggestion would be:
a) One the partitioning screen a button that says "My other OS is not shown" which then scans for an mbr table and shows the non-bootable Windows partition.
b) A quick bit of text that says "This operating system seems to be configured in a way that will not boot. If you know this is incorrect you may override the installation"
c) If the user clicks "yes" continue the install but assume that the system is a BIOS partition ignoring all evidence to the contrary.

[martinr (martinr1111)]

Steve Langasek (vorlon) wrote on 2013-01-15:
> The current on-disk layout tells you even *less* about how
> the disk will be booted than the current boot method for the removable media
> tells you.

Dear Steve, if the goal is:
Create a dual boot system on top of a pre installed Win7x64.

Why would the on-disk layout not tell you anything about how Win7x64 is currently installed an how it can be booted?
The system gets its operating system from the disk and obviously contains the only source of the bootable Win7x64 software.

You should not make any assumptions about which boot sequence will be used to boot the disk, because that is the real unknown here. (Assumptions are the mother of all f*ck-ups. :)
If you don't know and can't find out, just let the user decide / overwrite.

[Rod Smith (rodsmith)]

DavidEscott (david-escott) wrote:

> As a practical matter there really should be an override for the installer.

+1. I've seen a LOT of online problems reported because Ubuntu installs in one mode on a computer with another OS installed in another mode. Usually the existing install in EFI mode and Ubuntu installs in BIOS mode, although sometimes it's the other way around. My own suggestion is:

1. Ubiquity should look for an existing OS installation and try to infer its boot mode. This is easy with both Windows and OS X (except for naughty Hackintosh setups). It's harder for other Linuxes and BSDs.
2. If Ubiquity is booted in a mode that doesn't match inferred boot mode for the existing OS(es), put up a warning that briefly explains the issue and provide a URL to a document with more details. There can then be options depending on the boot mode:
  * If in BIOS mode, the options should be to abort or proceed with a BIOS-mode install.
  * If in EFI mode, the options should be to abort, to proceed with an EFI-mode install, or to switch to a BIOS-mode install.

All this said, I don't know how difficult it would be to modify Ubiquity to provide these options. I just know that the lack of such options is continuing to cause problems, even with 14.04. There's a whole cottage industry of tools to fix the problems, like Boot-Repair.