Ubuntu

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

Reported by YannUbuntu on 2012-07-13
366
This bug affects 76 people
Affects Status Importance Assigned to Milestone
grub2 (Debian)
Fix Released
Unknown
grub2 (Ubuntu)
Critical
Unassigned
os-prober (Ubuntu)
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 )

YannUbuntu (yannubuntu) on 2012-07-13
description: updated
YannUbuntu (yannubuntu) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Changed in grub2 (Ubuntu):
status: New → Confirmed
YannUbuntu (yannubuntu) on 2012-08-12
description: updated
Changed in grub2 (Debian):
importance: Undecided → Unknown
status: New → Unknown
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
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/

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
}

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) on 2012-09-14
description: updated
security vulnerability: no → yes
YannUbuntu (yannubuntu) wrote :

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

security vulnerability: yes → no
Launchpad Janitor (janitor) wrote :

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

Colin Watson (cjwatson) on 2012-10-16
affects: os-prober → os-prober (Ubuntu)
Changed in os-prober (Ubuntu):
status: New → Confirmed
YannUbuntu (yannubuntu) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Changed in os-prober (Ubuntu):
status: New → Confirmed
YannUbuntu (yannubuntu) on 2012-11-29
summary: - invalid Windows7 EFI entries in GRUB
+ invalid Windows EFI entries in GRUB
description: updated

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
}

YannUbuntu (yannubuntu) wrote :
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!

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/

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

@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) on 2013-01-08
summary: - grub-update generates MBR entries for GPT partitions
+ update-grub generates only BIOS based menu entries for Windows, even on
+ UEFI systems
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.

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.

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

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.

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

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

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

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

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)

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.

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.

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

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.

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

Phillip Susi (psusi) wrote :

You can't have both installed.

YannUbuntu (yannubuntu) wrote :

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

Steve Riley (steveriley) wrote :

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

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

hoel james (hoel-james) on 2013-05-09
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
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)".

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

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.

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

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)

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

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) on 2013-09-19
Changed in grub2 (Ubuntu):
status: Confirmed → Fix Released
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
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
To post a comment you must log in.
This report contains Public information  Edit
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.