Ubuntu

Windows7 EFI not detected by os-prober

Reported by YannUbuntu on 2012-06-26
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
os-prober (Ubuntu)
Undecided
Unassigned

Bug Description

PC with pre-installed Windows7 , GPT disk , EFI boot.

os-prober does not detect Windows, as seen here: http://paste.ubuntu.com/1057933

Bug initially reported here: http://askubuntu.com/questions/155492/why-cannot-ubuntu-12-04-detect-windows-7-dual-boot/156167#156167

Launchpad Janitor (janitor) wrote :

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

Changed in os-prober (Ubuntu):
status: New → Confirmed
Evertjan Garretsen (egarretsen) wrote :

Also see meta-bug Bug #1037351

Could not install Ubuntu for the installer did not see my windows installation and existing gpt partitions. It wanted to install on the full hard drive space! By doing so, i would have destroyed both my windows installation and recovery partition! This is very serious for inexperienced users! I had to find a way to let the installer see windows. After a lot of searching forums i found a (not ideal) solution: Removing the recovery partition of windows. Apparantly the last X blocks of a hard drive should be available for Ubuntu to see windows installed. After i removed the recovery partition, in the windows partitioner, Ubuntu installed just fine on a partition i wanted to use.

Please also add to 'Installer design' documentation. There should be a double check (or a working check) to see if another OS is already installated, otherwise this could lead to data-loss for inexperienced or unconcentrated users.

tags: added: efi
tags: added: windows
Newubunti (testtester257) wrote :

I've "created" - it had been more like copy & paste - an os-probes script from the existing 20microsoft. So I've now an additional script /usr/lib/os-probes/mounted/20mircosoft-efi. I'm not a programmer and not very good in writing script commands so do not expect, that the script is 100% bullet proof.

The script does

* check for bootmgfw.efi (MS EFI loader)
* check BCD for Windows-Version (same code like in 20microsoft)
* exit with code 1, even if MS EFI loader was found, cause IMO it's a good idea to keep the partition open for more EFI loader probing

The check is as simple as it had been so far for BIOS booting systems. That does mean that it does not check, if there is an existing main partition of Windows. But AFAIK from the change log this work is in progress already.

The attachment "20microsoft-efi" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Newubunti (testtester257) wrote :

Additional comments to my previous post #3:

* The script does not heal the problem, that update-grub (/etc/grub.d/30_os-prober) does not create a valid entry for the Windows EFI loader inside the GRUB menu.

* 30_os_prober does need some changes to create a valid entry for an EFI loader, cause chain loading of Windows EFI is different from Windows BIOS chainloading. It should be always:

chainloader /EFI/Microsoft/Boot/bootmgfw.efi

* To be able to create a different entry for Windows EFI loader in 30_os-prober the last section of the result row in 20microsoft-efi should may look like this:

result "${partition}:${long}:${label}:efi-chain"

IMO it would make sense, if the user can control, if he wants to have an entry added for Windows EFI loader inside GRUB menu, cause the selection of OS can be done inside the EFI boot menu of the system usually, too.

So an option like this needs to be added to grub-install/update-grub and a control needs to be set for this option inside ubiquity.

YannUbuntu (yannubuntu) wrote :

@Newubunti: thanks a lot for working on this. Your work may be complementary with this proposed patch: http://lists.debian.org/debian-boot/2012/10/msg00185.html

Newubunti (testtester257) wrote :

@YannUbuntu: thanks, you're right http://lists.debian.org/debian-boot/2012/10/msg00185.html does take the more advanced approach to resolve different problems with Ubuntu/Linux on EFI systems. It does do the same like my "patch" plus more.

I will let run some test installations with the patches from the debian list. So far I can see, they should resolve most of the problems with Ubuntu EFI installations I had been faced with.

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

Other bug subscribers