grub-installer should fall back to grub-pc instead of grub-efi when there is no EFI system partition

I started looking at this yesterday. The right thing to do is to fall back to grub-pc since the machine is normally bios booting, and they just used uefi to boot the cd.

I'd prefer the installer to fallback to grub-pc in this case.

So this actually turned out ot be very simple. I made the following change, and tested it in the following ways:

1) Boot in efi mode, do a use whole disk install. It created an efi system partition and used grub-efi.
2) Boot in efi mode, manually partition, remove the efi system partition, and replace it with bios_grub. It uses grub-pc, and booted fine in bios mode.
2) Installed 13.10 in bios mode, with an mbr partition table. Boot trusty in efi mode and do an along side install. It correctly used grub-pc, and boots fine in bios mode.

The patch is just this simple:

=== modified file 'grub-installer'
--- grub-installer 2014-03-28 13:11:31 +0000
+++ grub-installer 2014-04-08 16:22:27 +0000
@@ -442,6 +442,10 @@
  else
   grub_package="grub-efi"
  fi
+ if ! [ -d /target/boot/efi ]; then
+ #fall back to grub-pc
+ grub_package="grub-pc"
+ fi
  ;;
     powerpc/*)
  grub_package="grub-ieee1275"

I did notice two odd things in this process. The first is that when you manually partition the disk and don't have an esp, you get warned that you need one, but this warning does not happen when you do the guided install. I thought Colin mentioned on IRC that this warning should happen no matter how you get there. The second is that the menu option for the firmware setup that only applies for efi installs is still generated on the grub menu, even though we used grub-pc.

On Tue, Apr 08, 2014 at 04:28:34PM -0000, Phillip Susi wrote:
> The patch is just this simple:

Thanks. I'll probably sleep on it just to make sure my hindbrain has
had a chance to come up with objections, but this seems reasonably
plausible.

> I did notice two odd things in this process. The first is that when
> you manually partition the disk and don't have an esp, you get warned
> that you need one, but this warning does not happen when you do the
> guided install. I thought Colin mentioned on IRC that this warning
> should happen no matter how you get there.

Well, the check applies to the about-to-be-committed state, not the
initial state, so it happens just before committing the results of a
guided partitioning recipe or in the process of confirming manual
partitioning decisions, as appropriate.

Usually guided partitioning would ensure that an ESP exists (if the
target disk uses GPT). Are you saying that you set up a situation where
guided partitioning should have created an ESP but didn't? If so, could
you lay out the details?

> The second is that the menu option for the firmware setup that only
> applies for efi installs is still generated on the grub menu, even
> though we used grub-pc.

Yeah, the problem here is that the interface that grub.d scripts are
written to doesn't include a mechanism for determining which GRUB
platform is going to be used, and there are strange edge cases where you
might have support for multiple platforms installed in parallel, so it
gets complicated. Right now we apply the heuristic of testing for a
particular file in /sys/firmware/efi/vars, but this doesn't work here
because now the situation at install-time and boot-time might reasonably
differ.

I think the right answer is to test this at boot time instead, where we
can get a more accurate idea of the available facilities. The
efifwsetup module already does some of the necessary work: it only
registers the "fwsetup" command if (obviously) the module exists at all
(i.e. we're on EFI) and the appropriate OsIndicationsSupported variable
is set. This exactly corresponds to the conditions currently tested at
install time by /etc/grub.d/30_uefi-firmware. So the correct pseudocode
logic is simply:

  if fwsetup command exists; then
    menuentry 'System setup' --id 'uefi-firmware' {
      fwsetup
    }
  fi

There's one rather silly hitch, though. I don't think there's actually
a way to write the "fwsetup command exists" bit in GRUB script right
now! It would be a useful general facility to have for scripting, so
I'll take that up with grub-devel.

If there is an existing bios booting OS installed ( MBR partitioned disk ), and you choose to install along side to dual boot, you don't see the warning about not having an esp, and obviously one is not created.

That sounds correct. We only need a warning in the GPT case; the right
fix for the MBR case seems to be to install grub-pc, and no warning is
needed.

Tested the patch with beta 2 install DVD image (on USB stick) and my laptop (the one related to bug 1299134):

1. The installer finished without warning or error.
2. The grub installation fall back to use grub-pc. System boots successfully.

Thanks.

This bug was fixed in the package grub-installer - 1.78ubuntu20

---------------
grub-installer (1.78ubuntu20) trusty; urgency=medium

  * Fall back to grub-pc if there is no /target/boot/efi directory (thanks,
    Phillip Susi; LP: #1302418).
 -- Colin Watson <email address hidden> Wed, 09 Apr 2014 15:20:05 +0100

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/1302418

Regarding my comment #13 at duplicate bug #1050940 I now believe (after much investigation & help from others) that my issue was actually more firmware related than due to a bug in Ubuntu.

What had happened is that I installed Ubuntu Trusty in UEFI mode alongside Windows 8.1 (made sure that the live DVD booted in UEFI mode) but after installation the machine just booted straight into Windows 8.1. I knew however that you could display the BIOS boot menu pressing F10 so I did so, but Ubuntu did not show up anywhere in the boot menu, and selecting any of the other options either booted straight into Windows or did nothing at all.

I then ran Boot Repair just to collect a boot info summary and next actually ran the Boot Repair recommended repair (also collecting a second boot info summary when complete) and still the machine would just boot straight into Windows with no intervention, but if I pressed F10 at boot Ubuntu did now appear in the BIOS boot menu and selecting that showed the grub boot screen as it should with both Ubuntu and Windows - both of which worked OK.

It was at that point that I made the assumption that I'd been affected by duplicate bug #1050940 but I followed up by asking a question at the forums, and after following the instructions provided by oldfred I now get the grub boot menu at boot with no intervention:

http://ubuntuforums.org/showthread.php?t=2264348&p=13223803#post13223803

Sadly I still don't 100% understand what went wrong, or what exactly I did to fix it, but I now assume that I was mistaken about being affected by this specific bug.

Sorry, there's just a huge learning curve involved in learning UEFI basics and to be honest I'm not 100% certain which of my assumptions is correct and which is not.

BTW I'd have been glad to collect actual logs rather than just posting the pastebin links but I was unsure what was needed or where to find it :^(