[Bug 1302418] Re: grub-installer should fall back to grub-pc instead of grub-efi when there is no EFI system partition

[Colin Watson]

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.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub-installer in Ubuntu.
https://bugs.launchpad.net/bugs/1302418

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

Status in “grub-installer” package in Ubuntu:
  Confirmed
Status in “grub-installer” source package in Trusty:
  Confirmed

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)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1302418/+subscriptions