I also experienced this problem. Solved it using "boot-repair" tool downloadable from the internet. The author of the boot-repair tool has alot of knowledge about boot problems also regarding UEFI i think, maybe his knowledge can be used to make for a good dual boot experience using older hardware and newer UEFI hardware?

I've changed the title to something that I consider correct and appropriate as the last change was indeed incorrect.

Separately from the title, I wonder if it's possible to have a Windows installation which is bootable both via BIOS and via UEFI. If so, then it may not always be clear what type of entry to create at grub-mkconfig time and so it may be best to create both BIOS and UEFI based entries, but within an if statement that checks at boot to see if grub itself was loaded via UEFI or BIOS, and shows only the appropriate menu entry (this is currently possible, and not even difficult, to do with grub-script).

I don't know what to do though if we have for instance Windows installed in such a way that it can only be booted via BIOS, but Ubuntu's grub is being loaded via UEFI. In such a case there is nothing that grub can do to boot Windows, but just not showing the Windows entry is clearly not ideal. Possibly showing the Windows entry but giving a *clear* error message about why it can't be loaded is the solution there.

I agree with Jordan's new title.
And also with Phillip statement (You can't boot windows in bios mode if grub is booted in efi mode, and vice versa).

I saw several Windows installations which are bootable both via Legacy and via UEFI.
I agree with Jordan's suggestion to always create&display both Legacy and UEFI based Win entries.

+1 to add the error message too, and i suggest to add it 'live' at boot. For example, via grub-script we could maybe detect if grub was loaded in Legacy or UEFI; if loaded in Legacy mode, then it would add "(won't work unless BIOS is setup to boot in UEFI mode)" at the end of ALL uefi entries. And vice versa: if loaded in UEFI mode, it would add "(won't work unless BIOS is setup to boot in Legacy mode)" at the end of ALL bios entries. . In order to shorten the string and to avoid too much localization work, maybe eg "Ubuntu 13.04 (UEFI mode)" would be enough.
BTW, i know that "won't work unless BIOS is setup to boot in Legacy / UEFI mode" is not totally correct vocabulary (should be "won't work unless your firmware is setup to boot in BIOS / UEFI mode"), but that's what users will generally find in their firmwares, so let's make their life easier ;)

If you know one won't work, then there's no point in adding it. At update-grub time, you know if you are EFI and should search for an EFI bootable windows. It might be nice if you can detect that the windows install is only bios bootable and warn about the problem, but I'm not sure it's possible to get such a setup.

Last I heard, Windows can not be installed on GPT without EFI. If that is the case, then an EFI booting system can't have a bios booting windows install.

> At update-grub time, you know if you are EFI and should search for an EFI bootable windows.

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 ).
2) Windows is installed in UEFI mode, but update-grub is used from a Legacy mode live-session because the BIOS is set up to boot the CD/USB in Legacy mode
3) Windows is installed in Legacy mode, but update-grub is used from an UEFI mode live-session because the BIOS is setup to boot the CD/USB in UEFI mode.

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 ). 2) Windows is installed in
> UEFI mode, but update-grub is used from a Legacy mode live-session
> because the BIOS is set up to boot the CD/USB in Legacy mode 3)
> Windows is installed in Legacy mode, but update-grub is used from
> an UEFI mode live-session because the BIOS is setup to boot the
> CD/USB in UEFI mode.

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.

Maybe it has the files there anyhow, but is it possible to install
windows on a gpt disk without EFI? Either way it's a moot point
though since you can't boot windows in a mode other than the one grub
is booted in.

> You don't run update-grub from a live session; you have to chroot into
> the install and run it from there

of course :)

> , where you are running the correct version, regardless of how you booted the livecd.

what do you mean by 'version', is it 'grub-pc' vs 'grub-efi' ?
if yes, which entries would you hide if both grub-pc and grub-efi are installed in the installed Ubuntu? (i would suggest no hiding in this case)

(In post #25, I thought that you were referring to [[ -d /sys/firmware/efi ]] when writing 'At update-grub time, you know if you are EFI'. But i think now that you were refering to grub-efi / grub-pc presence in the install , as that would make more sense. Sorry for the confusion.)

> is it possible to install windows on a gpt disk without EFI?

i don't know. Also, maybe OEM have more install possibilities than a standard Win user.

> you can't boot windows in a mode other than the one grub is booted in.

agreed. And the mode grub (of the installed Ubuntu) is booted in is the mode in which the firmware is set up to boot the HDD (which can be different from the mode to boot the USB/CD).

On 1/10/2013 2:18 AM, YannUbuntu wrote:
> what do you mean by 'version', is it 'grub-pc' vs 'grub-efi' ? if
> yes, which entries would you hide if both grub-pc and grub-efi are
> installed in the installed Ubuntu? (i would suggest no hiding in
> this case)

Yes. grub-pc adds a bios boot entry if it finds windows. grub-efi
adds an efi boot entry if it finds windows. Adding both entries when
only one can work would be useless clutter.

Same here, i manually disabled bad entries like /dev/sdXY and use the good ones (EFI entries). Still, whenever I get an update the entries show up again. This is not a huge problem for me, but it would be awesome if grub could fix this and I didn't have to edit my config again. Also, this is probably a different kind of bug, but it recognizes a lot of backup efi's like "bootx64.efi.bkp" or something like that and labels them as "Windows 8 EFI" . I'd wish it said "Windows 8 EFI - Backup" and the regular efi files were labeled correctly. I think it all has to do with the same thing (my opinion as an independent developer/user), probing for OS's and examining file contents.

@Christopher:
- your EFI entries have been added by Boot-Repair, you can rename them by modifying your /etc/grub.d/25_custom file. This is not related to the bug we are talking about here.
- the fact that you have some "bad entries like /dev/sdXY" (that come back because automatically generated by update-grub) is exactly the bug we are talking about.

IMHO:
1) if only grub-pc is installed, then we should add Legacy entries only
2) if only grub-efi is installed, then we should add UEFI entries only
3) if grub-pc AND grub-efi are installed, then we should add Legacy AND UEFI entries

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:

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)".

On 5/17/2013 10:38 AM, Joseph Emenaker wrote:
> Phillip Susi wrote:
>> 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.

You don't seem to have understood the passage you quoted. Let me try
rephrasing it: when you boot from the livecd and update grub, you
first chroot into the hard drive, so you are running the update-grub
version on the hd, not the cd. Thus, if you installed the system
originally in efi mode and it has grub-efi installed, and you boot the
cd in bios mode, you are still running the efi version of update-grub
when you chroot into the hd, so the fact that you booted the livecd in
bios mode does not matter.

> 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 }

We're not going to support having both installed at the same time and
using the same config. You need to pick which mode you want to use
and stick with it, not flip flop every other boot. In addition,
Windows can not be booted in bios mode on a GPT disk, so you have to
use grub-efi anyhow.

On 5/17/2013 8:17 AM, Phillip Susi wrote:
> You don't seem to have understood the passage you quoted. Let me try
> rephrasing it: when you boot from the livecd and update grub, you
> first chroot into the hard drive, so you are running the update-grub
> version on the hd, not the cd.

True, looking back through it, I think I misinterpreted it. I took the
original idea to be "use the mode (UEFI vs BIOS) which was used for this
current boot session". You can generate a grub.cfg for another system
without needing to chroot. grub-mkconfig lets you redirect the output to
any file you want. So, what's to prevent a user from booting a recovery
CD and, without using chroot, using:

grub-mkconfig -o /media/MyRealUbuntuPartition/boot/grub/grub.cfg

> We're not going to support having both installed at the same time and
> using the same config. You need to pick which mode you want to use
> and stick with it, not flip flop every other boot. In addition,
> Windows can not be booted in bios mode on a GPT disk, so you have to
> use grub-efi anyhow.

But other OS's *can*. I can boot my linux partitions in UEFI or BIOS
mode. Furthermore, linux is what I turn to when I have trouble booting
any of my partitions. If I can just get to a linux prompt, with
fdisk/parted/grub/etc, then I can usually fix any other booting
problems. So, it would be helpful to be able to boot a linux partition
from BIOS mode if the EFI SP gets hosed. You can choose not to support
that; that's your choice, but I think there are scenarios wherein it
would be useful.

On 5/17/2013 12:32 PM, Joseph Emenaker wrote:
> True, looking back through it, I think I misinterpreted it. I took
> the original idea to be "use the mode (UEFI vs BIOS) which was used
> for this current boot session". You can generate a grub.cfg for
> another system without needing to chroot. grub-mkconfig lets you
> redirect the output to any file you want. So, what's to prevent a
> user from booting a recovery CD and, without using chroot, using:
>
> grub-mkconfig -o /media/MyRealUbuntuPartition/boot/grub/grub.cfg

Nothing, just like nothing prevents you from dd'ing /dev/zero all over
your drive. Don't do that. If you are trying to get a correct
grub.cfg, then you have to chroot since grub-mkconfig generates a
config to boot the system it finds in the current root.

> But other OS's *can*. I can boot my linux partitions in UEFI or
> BIOS mode. Furthermore, linux is what I turn to when I have trouble
> booting any of my partitions. If I can just get to a linux prompt,
> with fdisk/parted/grub/etc, then I can usually fix any other
> booting problems. So, it would be helpful to be able to boot a
> linux partition from BIOS mode if the EFI SP gets hosed. You can
> choose not to support that; that's your choice, but I think there
> are scenarios wherein it would be useful.

Whether it is useful or not, it isn't related to the subject of this
bug, which is booting windows.

On Fri, May 17, 2013 at 3:17 PM, Phillip Susi <email address hidden> wrote:
> We're not going to support having both installed at the same time and
> using the same config. You need to pick which mode you want to use
> and stick with it, not flip flop every other boot.

Upstream grub has done a lot of work to make sure that you *can* have
support for multiple platforms installed and in use at the same time,
with the same config. That is why the single grub-install and
grub-mkconfig scripts are identical no matter what target you build
grub for, which allows distributions to package them (and other files)
as common files, and platform specific files as separate packages, all
of which can be installed, and used, at the same time. It's why
modules were moved to /boot/grub/$arch-$platform (so that grub-install
can be run multiple times with different target platforms without
modules for the other platform being clobbered). Ubuntu allows
grub-pc, grub-efi-ia32, grub-efi-amd64, grub-coreboot, and all other
platform packages to be concurrently installed, and they work in such
a configuration.

In fact I would go so far as to say that upstream's opinion is exactly
opposite yours: I don't expect that any patch would be accepted which
would hinder support of having multiple platforms installed, all using
the same grub-mkconfig generated grub.cfg, without a *very* compelling
reason.

On 5/18/2013 12:14 AM, Jordan wrote:
> Upstream grub has done a lot of work to make sure that you *can* have
> support for multiple platforms installed and in use at the same time,
> with the same config.

I've notice that same thing. Right after I suggested "chainloader-efi"
and "chainloader-mbr" entries, I came across references to *already*
supported options for grub's "search" command, like "--hint-efi",
"--hint-bios", and "--hint-baremetal"... all of which can supersede the
"--hint" option.

So, it appears that upstream is already thinking along the lines of "one
grub to rule them all".

Hello, grub2 on Ubuntu has lots of problems.
Having Secure Boot enabled, grub2 is unable to load its modules to chainload Windows 8.
Having Secure Boot disabled, grub2 is able to load its modules to chainload Windows 8, but Windows 8 complains about Secure Boot and a watermark appaers on the wallpaper.

Same bug here: I'm running Kubuntu 15.10 and I can't boot Windows10.
If I pick Windows10 entry in the grub menu selection I obtain the same message error written in the first post: "Invalid EFI file path".

WORKAROUND with 'Secure Boot' DISABLED
--------------------------------------
The 'grub.cfg' menuentry below, which may conceivably be generated by 'os-prober', works only with 'Secure Boot' disabled :

FIXING THE BUG FOR ALL CASES
----------------------------
I suggest that 'os-prober' automatically performs the workaround just above, which involves copying boot files from the Windows partition to the 'EFI boot' partition.

Correction :
In the WORKAROUND with 'Secure Boot' ENABLED, you must NOT reference the Windows partition, but the 'EFI boot' partition :
Simply replace the set of '--hint-*=*' parameters by the output of 'sudo grub-probe -t hints_string /boot/efi'.

This bug is (at least in our case) caused by libblkid (through udevd/udevadm) reporting the disklabel type as "dos" while the os-prober script looks for "msdos". This was fixed upstream in Debian os-prober 1.76 as a fix for Debian bug #817023 for which I have attached the patch, though I recommend pulling the upstream changes directly.

The attachment "Debian commit 6dba9e66 fixes debian #817023 and helps fix ubuntu #1024383 was released as debian version 1.76" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

Peter, I just noticed your more recent comment. I was pretty certain this was fixed some time ago because os-prober will refuse to generate a bios windows entry if you are running in EFI mode, but it sounds like you are still seeing this. Are you running an older release?