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

Bug #1024383 reported by YannUbuntu
430
This bug affects 90 people
Affects Status Importance Assigned to Milestone
grub2 (Debian)
Fix Released
Unknown
grub2 (Ubuntu)
Fix Released
Critical
Unassigned
os-prober (Ubuntu)
Fix Released
Critical
Unassigned

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 )

Tags: patch efi windows
YannUbuntu (yannubuntu)
description: updated
Revision history for this message
YannUbuntu (yannubuntu) wrote :

Reproduced by another Win7 / 12.04 user: http://ubuntuforums.org/showthread.php?t=2023576

Revision history for this message
YannUbuntu (yannubuntu) wrote :
Revision history for this message
YannUbuntu (yannubuntu) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in grub2 (Ubuntu):
status: New → Confirmed
YannUbuntu (yannubuntu)
description: updated
Changed in grub2 (Debian):
importance: Undecided → Unknown
status: New → Unknown
Revision history for this message
znorrt (crouick) wrote :

I'm affected by this bug on 64 bits

(dual boot ubuntu 12.04 / windows seven with efi/gpt)

First i had to modify (with help) grub.cfg

But at every grub update i had to do it again

so, i used boot-repair (with some help) to modify the grub menu

in french : http://forum.ubuntu-fr.org/viewtopic.php?pid=10354211#p10354211

Changed in grub2 (Debian):
status: Unknown → New
Revision history for this message
Evertjan Garretsen (egarretsen) wrote :

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?

see http://sourceforge.net/p/boot-repair/home/Home/

Revision history for this message
YannUbuntu (yannubuntu) wrote :

Another example:
http://ubuntuforums.org/showpost.php?p=12198689&postcount=11

We can see the buggy entry created by os-prober:

### BEGIN /etc/grub.d/30_os-prober ###
menuentry "Windows 7 (loader) (on /dev/sda3)" --class windows --class os {
 insmod part_gpt
 insmod ntfs
 set root='(hd0,gpt3)'
 search --no-floppy --fs-uuid --set=root 8A3A9F1B3A9F02FD
 chainloader +1
}

And the correct entries created by Boot-Repair:

### BEGIN /etc/grub.d/40_custom ###
menuentry "Windows bootmgfw.efi, generated by Boot-Repair" {
search --fs-uuid --no-floppy --set=root 18FE-69D8
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi
}

menuentry "Windows memtest.efi, generated by Boot-Repair" {
search --fs-uuid --no-floppy --set=root 18FE-69D8
chainloader (${root})/EFI/Microsoft/Boot/memtest.efi
}

menuentry "Boot bootx64.efi, generated by Boot-Repair" {
search --fs-uuid --no-floppy --set=root 18FE-69D8
chainloader (${root})/EFI/Boot/bootx64.efi
}

Revision history for this message
Christophe Espiau (christophe-espiau) wrote :

I'm affected too.

As znorrt in post #5, dual boot ubuntu 12.04 / windows seven with efi/gpt.
Solved using boot-repair.

Details here (in French):
http://forum.ubuntu-fr.org/viewtopic.php?pid=10705531#p10705531

YannUbuntu (yannubuntu)
description: updated
Revision history for this message
YannUbuntu (yannubuntu) wrote :
security vulnerability: no → yes
Revision history for this message
YannUbuntu (yannubuntu) wrote :

@Got: AFAIK, this bug is not related to Security

security vulnerability: yes → no
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Colin Watson (cjwatson)
affects: os-prober → os-prober (Ubuntu)
Changed in os-prober (Ubuntu):
status: New → Confirmed
Revision history for this message
YannUbuntu (yannubuntu) wrote :

Related bug: #807801 (os-prober does not detect Windows UEFI)

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in os-prober (Ubuntu):
status: New → Confirmed
Revision history for this message
YannUbuntu (yannubuntu) wrote :
YannUbuntu (yannubuntu)
summary: - invalid Windows7 EFI entries in GRUB
+ invalid Windows EFI entries in GRUB
description: updated
Revision history for this message
YannUbuntu (yannubuntu) wrote : Re: invalid Windows EFI entries in GRUB

Example of invalid Windows8 entry on UEFI system:

http://ubuntuforums.org/showpost.php?p=12379417&postcount=32

menuentry 'Windows 8 (loader) (on /dev/sda3)' --class windows --class os $menuentry_id_option 'osprober-chain-98F2-07ED' {
 insmod part_gpt
 insmod fat
 set root='hd0,gpt3'
 if [ x$feature_platform_search_hint = xy ]; then
   search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3 98F2-07ED
 else
   search --no-floppy --fs-uuid --set=root 98F2-07ED
 fi
 drivemap -s (hd0) ${root}
 chainloader +1
}

Revision history for this message
YannUbuntu (yannubuntu) wrote :
Revision history for this message
Shashi Thutupalli (stpalli) wrote :

Hi,

I have the same problem with a Lenovo Thinkpad X230, pre-installed with Windows 8. a fix would be greatly appreciated!

Revision history for this message
falstaff (falstaff) wrote :

I made a script which creates working boot entries for Windows 7/8 as long as the EFI system partition is mounted at /boot/efi (which normally happens):

https://gist.github.com/4330598

Use it like this:

$ wget https://gist.github.com/raw/4330598/adaf598a78d568dbfada596441bdfad3b4dd3f97/25_windows_uefi
$ sudo su
# cp 25_windows_uefi /etc/grub.d
# chmod +x /etc/grub.d/25_windows_uefi
# echo GRUB_DISABLE_OS_PROBER=true >> /etc/default/grub # disable broken os-prober
# update-grub

See also this blog post how to install Grub with Secure Boot mode (if installer fails to do it)

http://falstaff.agner.ch/2012/12/18/ubuntu-12-10-and-windows-8-with-secure-boot-mode/

Revision history for this message
Warren Post (warren-post) wrote :

I'm affected too, on an HP 1000-1210LA laptop with Windows 8 pre-installed.

summary: - invalid Windows EFI entries in GRUB
+ grub-update generates MBR entries for GPT partitions
Changed in os-prober (Ubuntu):
importance: Undecided → Critical
Changed in grub2 (Ubuntu):
importance: Undecided → Critical
Revision history for this message
YannUbuntu (yannubuntu) wrote : Re: grub-update generates MBR entries for GPT partitions

@Andrea: i think you renamed the title incorrectly, because the bug applies only to UEFI systems entries. Some systems can use MBR even when located on GPT partition (eg using a BIOS-boot partition).

Jordan (jordanu)
summary: - grub-update generates MBR entries for GPT partitions
+ update-grub generates only BIOS based menu entries for Windows, even on
+ UEFI systems
Revision history for this message
Jordan (jordanu) wrote :

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.

Revision history for this message
Phillip Susi (psusi) wrote :

You can't boot windows in bios mode if grub is booted in efi mode ( since there is no bios ), and vice versa.

Just to make sure, you do have grub-efi installed, and not grub-pc right? Check with apt-cache policy grub-efi and apt-cache policy grub-pc.

Revision history for this message
YannUbuntu (yannubuntu) wrote :

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 ;)

Revision history for this message
Phillip Susi (psusi) wrote :

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.

Revision history for this message
YannUbuntu (yannubuntu) wrote :

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

> an EFI booting system can't have a bios booting windows install.

I am nearly sure of the contrary, because many preinstalled Windows come with both files to be booted in UEFI and Legacy modes.
Examples: http://paste.ubuntu.com/1495850, http://paste.ubuntu.com/1479512 , http://paste2.org/p/2700549

Revision history for this message
Phillip Susi (psusi) wrote : Re: [Bug 1024383] Re: update-grub generates only BIOS based menu entries for Windows, even on UEFI systems

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

>> an EFI booting system can't have a bios booting windows install.
>
> I am nearly sure of the contrary, because many preinstalled Windows
> come with both files to be booted in UEFI and Legacy modes.
> Examples: http://paste.ubuntu.com/1495850,
> http://paste.ubuntu.com/1479512 , http://paste2.org/p/2700549

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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ7Ph2AAoJEJrBOlT6nu75ccgH/1b2NXUnpoQN/jiO0y+22HBs
eKPX1Z330ocTeJhl56g+CFtiUuHGpwOu9mzmQTbaeKKSuGWboDe7XW8lXOxd2JaC
Cozpw8zQa8KxOic+EsrqNWPk68Wy9Xy5EtOoSygCxEZwo9HXm1bhGwIvBEYq8pn7
gcM4w+LNh25QnMDctkTTxKezQyrF8zSVziomybEBRy1tXt3ai5ENqrWv4MUyIjxk
249oCwcJrrtYNEfaFNZyAIincoFMLd4IeiM3f0lyvvoSZZa4WlgAh/mGu/qxfThe
CNieL5KZcc9WEtThtAcstoZOLOfh76HykO04iEsZ6h7tmj+dJxkltqXbhcxpmmY=
=fREm
-----END PGP SIGNATURE-----

Revision history for this message
YannUbuntu (yannubuntu) wrote :

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

Revision history for this message
Phillip Susi (psusi) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ7uS/AAoJEJrBOlT6nu75JEsIAI1Pz1qvf9Lr2JABQxZeDgRs
HrAHDTayDV3d4M5qyMUBHuppYGKtnIZ04urQqILB5T/avPxDiG7gGsklbn7UXcQO
m9ZHEvA3nAu3cTHfNnnC3V6P6ajDWKrcJZaFnUzaPSnXB5RIhHLRW3M1RQKlJy4g
DU55fFICBkkjpets6fvp07MCJAmb5apTPrlO4nNxQmUpVB7yZ3MigmLleciKXo2o
ppQ9X/UUQWMtBIsc3Qhp6XmudrjVOJJ7OJ5MZ3jrLvqS5BSlkKuR+wGyNsv4oEhr
zQgn/CPlybHcx8LNJEoiDeFrAe3SNrDd9JN9BVlotd25zU4AdOlIeVdzX2RQa0w=
=fAwl
-----END PGP SIGNATURE-----

Revision history for this message
YannUbuntu (yannubuntu) wrote :

yes, grub-mkconfig should add Legacy AND/OR uefi entries according to the presence of grub-pc AND/OR grub-efi in the install.

(not only if it finds windows, whatever the systems it finds)

Revision history for this message
Christopher Welborn (cjwelborn) wrote :

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.

Revision history for this message
YannUbuntu (yannubuntu) wrote :

@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.

Revision history for this message
Miguelángel León (migueleonm) wrote :

@Phillip Obviously you don't see the problem.

The problem is, Ubuntu installs grub-efi if the pc is in uefi mode but adds a bios windows 8 entry even when the windows 8 is in uefi mode.

Revision history for this message
Phillip Susi (psusi) wrote :

Yes, I got that. Yannu was suggesting that grub add both entries. I just said adding both is pointless since only one will work. Obviously, the *correct* one should be added, and not the other.

Revision history for this message
YannUbuntu (yannubuntu) wrote :

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

Revision history for this message
Phillip Susi (psusi) wrote :

You can't have both installed.

Revision history for this message
YannUbuntu (yannubuntu) wrote :

yep, but it would be nice if we could ;) see Bug #1111950

Revision history for this message
z (steveriley-deactivatedaccount-deactivatedaccount) wrote :

Another report, from one of our members at Kubuntu forums.

http://www.kubuntuforums.net/showthread.php?62191

hoel james (hoel-james)
Changed in os-prober (Ubuntu):
assignee: nobody → hoel james (hoel-james)
Changed in grub2 (Ubuntu):
assignee: nobody → hoel james (hoel-james)
assignee: hoel james (hoel-james) → nobody
Changed in os-prober (Ubuntu):
assignee: hoel james (hoel-james) → nobody
Revision history for this message
Joseph Emenaker (u-joe) wrote :

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

Revision history for this message
Phillip Susi (psusi) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRlkohAAoJEJrBOlT6nu75nwsIANiwbP69KtehXZNvPbDLxcGF
1MOAkSkb9jtwNciHaKsz8s/EK9/3vyuSBgXOj5QeoxaTwtCO7v6WwZM65z7vqCkc
Ndz32fqAK12ZyTphLKn/oetiBFyOKGqE9xC+WBgjNhYiRWHgxmZoMcGAQXboCLSL
aJsyCs4V5jAWjq2zQ/p7cFO4C7iqaajHX+lmGLTaCX6LLzdp8UoaL/zCBG51pUZe
0Z5X6kcJtPAAxaPXTlXUbUpjRuOIdLTW50DPx+iGxBKAdHj2C7l02mRyPpGSBxWe
k3XIeFjCx9eXBSY+zwUW24sftBY+4p+2xFc2tyHu2S6bx1s97lK7NBioYX5Hg04=
=w04L
-----END PGP SIGNATURE-----

Revision history for this message
Joseph Emenaker (u-joe) wrote :

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.

Revision history for this message
Phillip Susi (psusi) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRlm98AAoJEJrBOlT6nu75uawIAMOaATtu9mdO/F7QcK/0uTIT
pj726M/llhJiPLm9vuNKQCJnHkjP2suk+9Z1+DcelgkqlXc9QYINUXZpJdjQ2wbD
iB2WpnIQrBt6yYHuewYtssW0VdM+wikc3z+2Q3JqjKsyFJHJZxfeesjTejK8zF1z
ijXHdym9KtZrJXIU66VhrViI24fDOJRCr6mU/ncwdD2tkGXzkB5wbQpwy/18wh4G
MB8hb61g7qW+WLlVJG/DP0M/7IjjLQWiUU3pdnz+EGes+tt760nFXI4HdKiUv6of
nMvn1Mq6grq1W8tXfalfMCnD5SCvT+fvOzLHglyONzjjpR8KD/yuc0+e1Rh5Efk=
=+ZQa
-----END PGP SIGNATURE-----

Revision history for this message
Jordan (jordanu) wrote :

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.

--
Jordan Uggla (Jordan_U on irc.freenode.net)

Revision history for this message
Joseph Emenaker (u-joe) wrote :

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

Revision history for this message
Johnny Swanson (jswanson3703) wrote :

I am also affected by this bug; boot-repair did not work for me. I have a Samsung Series 3 laptop which has EFI and was distributed with Windows 8 64-bit. http://paste.ubuntu.com/5719692 and http://paste.ubuntu.com/5719766

lmg (lawmago)
Changed in grub2 (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Phillip Susi (psusi) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

affects ubuntu/grub2
status confirmed
thanks

Please don't mark bugs as fixed for no apparent reason.

On 9/19/2013 12:14 PM, lmg wrote:
> ** Changed in: grub2 (Ubuntu) Status: Confirmed => Fix Released
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSO2ATAAoJEJrBOlT6nu75PUwH/1x340O1oAk3Op0FGXH1O0hT
XmBI3IHnsj9xdE8YKRJLIk5BWLInvI+ACVUEtWkfxwH7kWdnQpU9H+Q4gksm+ZKe
Mf2G48XIWgFeKqHeWNXZxI73AGwAtLCPvikMjYMIqqSgu0cRBlQSitIAFd9C5KxQ
+FIlWIxSX/2psJPMDJNayaQsRRLbDqDLNpzvh9dMcK7BjMXjoJpDNYRiBr59dqEr
O4gSoMmmBbicYN4u8kVQwFoqnw1QDiOj5ZIZ0IL80dRcEgjebHrJVtNLun98CR+o
k0Ha/m+SYE7f8vjzLj5OCdo+ONfjK08dwa3oQseY1bkxbjZ3faHNZ/HQIMU9m7Q=
=NnHa
-----END PGP SIGNATURE-----

Changed in grub2 (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
Teodori Serge (teodori-serge) wrote :

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.

Changed in grub2 (Debian):
status: New → Fix Released
Revision history for this message
josef lauri (josef-lauri) wrote :

I have exactly this same problem. I ran boot-repair but the problem was not resolved. Th output from boot-repair can be found on

http://paste.ubuntu.com/8350528

Thanks for any helpful advice. I read through some of the posts above, but if the solution is there I might not have sufficient ubuntu expertise to recognise it :(

Thanks.

Revision history for this message
Yo (yleduc) wrote :

#FIRST

sudo rm /etc/X11/xorg.conf
sudo apt-get purge nvidia*

#AND

sudo apt-add-repository ppa:bumblebee/stable

Changed in grub2 (Ubuntu):
status: Confirmed → Fix Released
Changed in grub2 (Ubuntu):
status: Fix Released → Confirmed
Changed in os-prober (Ubuntu):
assignee: nobody → Sushmita (sush-patil-mita)
Revision history for this message
Phillip Susi (psusi) wrote :

Assignment is for a developer who is working on fixing the issue; please do not use it otherwise.

Changed in os-prober (Ubuntu):
assignee: Sushmita (sush-patil-mita) → nobody
Revision history for this message
Mauro D'Aloisio (maurodaloisio) wrote :

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

apt-cache policy grub-efi
grub-efi:
  Installato: 2.02~beta2-29ubuntu0.3
  Candidato: 2.02~beta2-29ubuntu0.3
  Tabella versione:
 *** 2.02~beta2-29ubuntu0.3 0
        500 http://it.archive.ubuntu.com/ubuntu/ wily-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2.02~beta2-29ubuntu0.2 0
        500 http://security.ubuntu.com/ubuntu/ wily-security/main amd64 Packages
     2.02~beta2-29 0
        500 http://it.archive.ubuntu.com/ubuntu/ wily/main amd64 Packages

Revision history for this message
Etienne URBAH (eurbah) wrote :

In order to boot Windows on UEFI systems :

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

menuentry "Windows booted from its NTFS partition" {
    insmod part_msdos # and/or part_gpt, depending on the partition table(s)
    insmod ntfs
    set WindowsEFI=/EFI/Microsoft/Boot/bootmgfw.efi
    if [ x$feature_platform_search_hint = xy ]; then
      search -n -s --hint-bios=hd0,msdos2 --hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2 -f $WindowsEFI
    else
      search -n -s -f $WindowsEFI
    fi
    chainloader $WindowsEFI
}

But with 'Secure Boot' enabled, the above menuentry systematically fails with following error message :
Secure boot forbids loading module from (hd0,msdos2)/boot/grub/x86_64-efi/ntfs.mod

WORKAROUND with 'Secure Boot' ENABLED
-------------------------------------
In order to boot Windows on UEFI with 'Secure Boot' enabled, I have successfully installed following workaround :

- Think : On installation of the Linux distribution (Ubuntu or another one) with UEFI, the installer normally creates an 'EFI boot' partition formatted as 'vfat'.

- Think : This 'EFI boot' partition is read by 'grub' WITHOUT the need of the insecure 'ntfs.mod', and is precisely dedicated to booting. So, let's use it :

- Under Linux, mount the Windows partition, and copy the content of its '/EFI' folder under '/boot/efi/EFI'. For example :
   sudo cp -p -r /media/user/Windows-Label/EFI/* /boot/efi/EFI/
   (you can safely ignore 'cp: failed to preserve ownership' error messages)

- Then, replacing 'msdos2' by the partition number of the Windows partition on your system, write following lines at the END of '/etc/grub.d/40_custom' :

menuentry "Windows booted from EFI boot partition" {
    insmod part_msdos # and/or part_gpt, depending on the partition table(s)
    set WindowsEFI=/EFI/Microsoft/Boot/bootmgfw.efi
    if [ x$feature_platform_search_hint = xy ]; then
      search -n -s --hint-bios=hd0,msdos2 --hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2 -f $WindowsEFI
    else
      search -n -s -f $WindowsEFI
    fi
    chainloader $WindowsEFI
}

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.

Revision history for this message
Etienne URBAH (eurbah) wrote :

Concerning comment #51 just above :

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'.

Addition :
Before rebooting, run 'sudo update-grub'.

Gabriela (gabriela68)
Changed in grub2 (Ubuntu):
status: Confirmed → Fix Released
Changed in os-prober (Ubuntu):
status: Confirmed → Fix Released
Changed in grub2 (Ubuntu):
assignee: nobody → Gabriela (gabriela68)
Changed in os-prober (Ubuntu):
assignee: nobody → Gabriela (gabriela68)
Phillip Susi (psusi)
Changed in grub2 (Ubuntu):
status: Fix Released → Confirmed
assignee: Gabriela (gabriela68) → nobody
Changed in os-prober (Ubuntu):
status: Fix Released → Confirmed
assignee: Gabriela (gabriela68) → nobody
Revision history for this message
Jeb E. (jebeld17) wrote :
Download full text (45.2 KiB)

I've had several times an update to my Ubuntu install has corrupted my Windows Boot Manager.
See my Paste:
http://paste2.org/kpXd5p6k

-----
Boot Info Script cfd9efe + Boot-Repair extra info [Boot-Info 26Apr2016]

============================= Boot Info Summary: ===============================

 => Windows 7/8/2012 is installed in the MBR of /dev/sda.

sda1: __________________________________________________________________________

    File system: vfat
    Boot sector type: -
    Boot sector info: No errors found in the Boot Parameter Block.
    Operating System:
    Boot files: /EFI/Boot/bootx64.efi /EFI/ubuntu/MokManager.efi
                       /EFI/ubuntu/fwupx64.efi /EFI/ubuntu/grubx64.efi
                       /EFI/ubuntu/shimx64.efi
                       /EFI/Microsoft/Boot/bootmgfw.efi
                       /EFI/Microsoft/Boot/bootmgr.efi
                       /EFI/Microsoft/Boot/memtest.efi

sda2: __________________________________________________________________________

    File system:
    Boot sector type: -
    Boot sector info:
    Mounting failed: mount: unknown filesystem type ''

sda3: __________________________________________________________________________

    File system: ntfs
    Boot sector type: Windows 8/2012: NTFS
    Boot sector info: No errors found in the Boot Parameter Block.
    Operating System:
    Boot files: /bootmgr /Windows/System32/winload.exe

sda4: __________________________________________________________________________

    File system: ntfs
    Boot sector type: Windows 8/2012: NTFS
    Boot sector info: No errors found in the Boot Parameter Block.
    Operating System:
    Boot files:

sda5: __________________________________________________________________________

    File system: ext4
    Boot sector type: -
    Boot sector info:
    Operating System: Ubuntu 16.10
    Boot files: /boot/grub/grub.cfg /etc/fstab

sda6: __________________________________________________________________________

    File system: swap
    Boot sector type: -
    Boot sector info:

============================ Drive/Partition Info: =============================

Drive: sda _____________________________________________________________________
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt

Partition Boot Start Sector End Sector # of Sectors Id System

/dev/sda1 1 1,953,525,167 1,953,525,167 ee GPT

GUID Partition Table detected.

Partition Attrs Start Sector End Sector # of Sectors System
/dev/sda1 2,048 1,026,047 1,024,000 EFI System partition
/dev/sda2 1,026,048 1,288,191 262,144 Microsoft Reserved Partition (Windows)
/dev/sda3 1,288,192 1,343,465,471 1,342,177,280 Data partition (Windows/Linux)
/dev/sda4 R 1,952,602,112 1,953,523,711 921,600 Windows Recovery Environment (Windows)
/dev/sda5 1,351,464,960 1,952,601,678 ...

Yo (yleduc)
Changed in grub2 (Ubuntu):
assignee: nobody → Yo (yleduc)
status: Confirmed → Fix Released
assignee: Yo (yleduc) → nobody
Revision history for this message
Phillip Susi (psusi) wrote :

Yo, stop marking this bug as fixed for no reason.

Changed in grub2 (Ubuntu):
status: Fix Released → Triaged
Changed in grub2 (Ubuntu):
status: Triaged → Incomplete
status: Incomplete → Confirmed
Revision history for this message
Jeb E. (jebeld17) wrote :

This happens in Windows 10 systems, too.
Dell Inspiron 13 5xxx series.

Revision history for this message
Etienne URBAH (eurbah) wrote :

With following packages from Kubuntu Bionic Beaver Beta1 (18.04) :
grub-efi-amd64 2.02-2ubuntu8
grub-efi-amd64-bin 2.02-2ubuntu8
grub-efi-amd64-signed 1.93+2.02-2ubuntu8
os-prober 1.74ubuntu1

On UEFI system 'MSI GE62 7RE-210FR', this issue appears to be solved :
- 'grub.cfg' contains a 'Windows Boot Manager' menuentry correctly referencing '/EFI/Microsoft/Boot/bootmgfw.efi' on a GPT partition,
- Booting with this 'grub.cfg' then choosing 'Windows Boot Manager' correctly starts 'Windows'.

Changed in grub2 (Ubuntu):
assignee: nobody → MOHAMMED FAHAD MUSHAHID (89mfahad)
Revision history for this message
Cavsfan (cavsfan) wrote :

I have a new PC SSD using UEFI/GPT and I am experiencing none of these problems booting Windows 10.
I installed Windows 10, then Xubuntu 16.04, Xubuntu 18.04 and today Xubuntu 18.10 with zero problems.
Boot entry for Windows 10 default:
menuentry 'Windows Boot Manager (on /dev/sdc1)' --class windows --class os $menuentry_id_option 'osprober-efi-688D-126B' {
 insmod part_gpt
 insmod fat
 set root='hd2,gpt1'
 if [ x$feature_platform_search_hint = xy ]; then
   search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt1 --hint-efi=hd2,gpt1 --hint-baremetal=ahci2,gpt1 688D-126B
 else
   search --no-floppy --fs-uuid --set=root 688D-126B
 fi
 chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

It does not fail to boot Windows 10.

Phillip Susi (psusi)
Changed in grub2 (Ubuntu):
assignee: MOHAMMED FAHAD MUSHAHID (89mfahad) → nobody
Revision history for this message
Peter Bosch (pbx) wrote :

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.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

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.]

tags: added: patch
Phillip Susi (psusi)
Changed in grub2 (Ubuntu):
status: Confirmed → Fix Released
Changed in os-prober (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Phillip Susi (psusi) wrote :

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?

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

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.