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

Bug #1302418 reported by Jean-Baptiste Lallement on 2014-04-04
144
This bug affects 48 people
Affects Status Importance Assigned to Milestone
grub-installer (Ubuntu)
Critical
Colin Watson
Trusty
Critical
Colin Watson

Bug Description

During a side-by-side installation, the EFI partition is not created.. If it doesn't already exist (which given recent bug reports seems to be the case on systems with MS Windows installed), installation fails at grub stage.

TEST CASE:
Note: This test case simulates in qemu the behavior found on real HW eg. bug 1299134

1. Install trusty in BIOS mode

$ qemu-img create -f qcow2 /tmp/disk.img 16G
$ qemu-system-x86_64 -enable-kvm \
    -drive file=/tmp/disk.img,if=ide,media=disk \
    -pflash /tmp/bios.bin \
    -cdrom $ISO

2. Reboot
3. Reuse the same disk and Install trusty in UEFI mode for example start qemu with the option -pflash=/tmp/ovmf.bin and the binary file attached to this bug report.

$ qemu-system-x86_64 -enable-kvm \
    -drive file=/tmp/disk.img,if=ide,media=disk \
    -pflash /tmp/bios.bin \
    -cdrom $ISO

4. Proceed to the partitioner and select a side-by-side installation
5. Proceed with the rest of the installation

ACTUAL RESULT:
This crash

EXPECTED RESULT:
There are several ways to address this issue, I see 2 options there are probably more:
1. Warn the user and refuse to proceed past the partitioner
2. Create an EFI partition like the entire disk installation does.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: ubiquity 2.17.10
ProcVersionSignature: Ubuntu 3.13.0-22.44-generic 3.13.8
Uname: Linux 3.13.0-22-generic x86_64
ApportVersion: 2.14-0ubuntu1
Architecture: amd64
CasperVersion: 1.339
Date: Fri Apr 4 10:36:19 2014
InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz.efi file=/cdrom/preseed/ubuntu.seed boot=casper quiet splash --
LiveMediaBuild: Ubuntu 14.04 LTS "Trusty Tahr" - Daily amd64 (20140403)
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: grub-installer
UpgradeStatus: No upgrade log present (probably fresh install)

Jean-Baptiste Lallement (jibel) wrote :
tags: added: rls-t-incoming
Jean-Baptiste Lallement (jibel) wrote :
description: updated
description: updated
Phillip Susi (psusi) wrote :

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.

summary: - auto-resize installation fails if efi partition doesn't already exists
+ grub-installer should fall back to grub-pc instead of grub-efi when
+ there is no EFI system partition
Changed in grub-installer (Ubuntu Trusty):
assignee: nobody → Canonical Foundations Team (canonical-foundations)
importance: Undecided → Critical
status: New → Confirmed
description: updated
Shu Hung (Koala) (koalay) wrote :

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

Steve Langasek (vorlon) on 2014-04-08
Changed in grub-installer (Ubuntu Trusty):
assignee: Canonical Foundations Team (canonical-foundations) → Colin Watson (cjwatson)
Colin Watson (cjwatson) on 2014-04-08
tags: removed: rls-t-incoming
Phillip Susi (psusi) wrote :

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.

Phillip Susi (psusi) wrote :

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.

Colin Watson (cjwatson) wrote :

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.

Colin Watson (cjwatson) on 2014-04-09
Changed in grub-installer (Ubuntu Trusty):
status: Confirmed → Fix Committed
Shu Hung (Koala) (koalay) wrote :

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.

Launchpad Janitor (janitor) wrote :

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

Changed in grub-installer (Ubuntu Trusty):
status: Fix Committed → Fix Released
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/1302418

tags: added: iso-testing
Erick Brunzell (lbsolost) wrote :

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 :^(

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

Other bug subscribers