[Bug 1024383] Re: update-grub generates only BIOS based menu entries for Windows, even on UEFI systems

[Joseph Emenaker]

Phillip Susi wrote:
> On 01/08/2013 09:41 PM, YannUbuntu wrote:
> > No, don't rely on the mode where grub-update is used !
> > Counter-examples: 1) Windows is installed in UEFI mode but
> > update-grub is used from a Ubuntu32bit liveCD (which cannot be
> > booted in UEFI mode, see Bug #1025555 ). 
> > ...
> You don't run update-grub from a live session; you have to chroot into
> the install and run it from there, where you are running the correct
> version, regardless of how you booted the livecd.
> ...

No, I think Yann is absolutely correct about this. My laptop can boot in
UEFI, BIOS, or a "mixed" mode (where it looks for a UEFI partition and
then, if not found, looks for a MBR boot record). The point, however, is
that I can boot SuperGRUB or a live-CD via BIOS/MBR booting off of a CD
or USB drive, and then mount the linux partition on my hard-drive, and
then run update-grub from there. That would be a case where my computer
booted via BIOS/MBR *just* for that recovery session, when "normal"
booting is going to be done via UEFI.

I've only been wrestling with GPT/UEFI for a couple of days, but I think
I'm starting to get an idea of the solution which is needed. For myself,
at least, the *ideal* solution would be to have the option of installing
GRUB to the EFI System Partition *and* to the MBR boot-record, so that
GRUB could be reachable no matter what boot mode I put my computer into
(and perhaps this is already possible, by installing both grub-efi and
grub-pc on the system. I haven't tried).

But it seems that the more-critical part of the solution would be for
there to be grub.conf directives specific to MBR and UEFI booting.
Imagine, for example:

menuentry "Windows 8" {
   set root-efi=(hd0,gpt2)
   set root-mbr=(hd0,2)
   chainloader-efi    /EFI/microsoft/BOOT/bootmgfw.efi
   chainloader-mbr +1
}

The need for separate "root=" entries could probably be avoided, but you
get the idea. There could still be support for plain "chainloader"
directive, but that value would be superseded by the more-specific
directives. Then, the grub-pc binary would look for additional
"chainloader-mbr" directives and the grub-efi binary would look for
additional "chainloader-efi" directives.

But that's going to take time and planning on the part of the up-stream
grub2 devs. In the short-term, however, I think update-grub should
probably be modified to use the EFI-compatible version of the
chainloader argument if it detects a mounted EFI partition (or whatever
test it uses to determine whether to use "set root=(hd0,1)" or "set
root=(hd0,gpt1)".

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

Title:
  update-grub generates only BIOS based menu entries for Windows, even
  on UEFI systems

Status in “grub2” package in Ubuntu:
  Confirmed
Status in “os-prober” package in Ubuntu:
  Confirmed
Status in “grub2” package in Debian:
  New

Bug description:
  64bits computer with pre-installed EFI Windows 7. (remark: same bug if
  Windows8)

  Installed Ubuntu 64bits in dual-boot. GRUB (grub-efi) is correctly
  installed and allows to boot Ubuntu, but it does not allow to boot
  Windows.

  Its menu shows 2 INVALID Windows entries. When selecting these
  entries, it displays "Invalid EFI file path" error, and returns to
  GRUB menu.

  It appears that GRUB creates BIOS/mbr entries when it should be
  UEFI/gpt type entries.

  *********************** WORKAROUND **************************

  either boot Windows from the (EFI) BIOS menu, or add valid Windows entries via Boot-Repair.
  ***************************************************************

  (original thread in French: http://forum.ubuntu-
  fr.org/viewtopic.php?pid=10010231#p10010231 )

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1024383/+subscriptions