Bug 971255 - After a BIOS install of Fedora to a hard disk containing a UEFI install of Windows 8, the Windows 8 install fails to boot
Summary: After a BIOS install of Fedora to a hard disk containing a UEFI install of Wi...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 19
Hardware: x86_64
OS: Unspecified
urgent
urgent
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1011252 1027624 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-06 06:52 UTC by A.J. Werkman
Modified: 2015-02-17 15:28 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-02-17 15:28:34 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Listing of /dev/sda2 (10.99 KB, text/plain)
2013-06-07 21:42 UTC, A.J. Werkman
no flags Details
Postwindows (2.00 KB, application/octet-stream)
2013-06-09 18:22 UTC, A.J. Werkman
no flags Details
Postfedora (2.00 KB, application/octet-stream)
2013-06-09 18:23 UTC, A.J. Werkman
no flags Details

Description A.J. Werkman 2013-06-06 06:52:39 UTC
Description of problem:
Installing F19 next to a Windows 8 installation, the grub menu does not show a Windows boot item

Version-Release number of selected component (if applicable):
19-TC1

How reproducible:
Everytime

Steps to Reproduce:
1. On an UEFI enabled system install Windows 8 using only a part of the disc space. Leave enough room for F19.
2. PXE-boot F19-TC1 installtion and install F19-TC1
3. reboot to the grub menu

Actual results:
Windows 8 is not shown as a boot item

Expected results:
Windows 8 should be shown as a boot item

Additional info:
Looks like by PXE booting, F19 does not recognize that it should install in EFI. Instead it does install non-EFI. In this environment EFI bootitems are not detected.

Comment 1 Vasilis Keramidas 2013-06-06 08:04:24 UTC
Please check if this bug helps you at all:

https://bugzilla.redhat.com/show_bug.cgi?id=873207

Comment 2 Robert Lightfoot 2013-06-06 12:00:17 UTC
What type of isntall was this.  There was a bug in 19-Beta-Gold where on minimal install the ntfs progs were not isntalled so thus os-prober couldn't find and setup windows.  I'd run rpm -qa | grep ntfs and make sure the ntfs-utils are isntalled.

Comment 3 A.J. Werkman 2013-06-06 13:52:22 UTC
Did a retest and installed GNOME-desktop. The error reoccured and no Win 8 boot entry was added to grub.

rpm -qa | grep ntfs result was:
ntfs-3g-2013.1.13-5.fc19.x86_64
ntfsprogs-2013.1.13-5.fc19.x86_64

There was no ntfs-utils and this could also not be installed through yum.

Comment 4 Adam Williamson 2013-06-06 17:23:37 UTC
ntfsprogs is it. I think you're on a better track with the UEFI/non-UEFI thing, A.J. But I think whether a PXE boot will be a UEFI or non-UEFI boot may be firmware-dependent. Let's CC the UEFI experts on that.

I don't think it's possible for a BIOS install of Fedora (or any Linux) to 'chainload' a UEFI install of Windows; once you get to grub2 you're already in 'BIOS compatibility mode' and there's no way you could break out into 'UEFI mode'. AIUI anyhow. So as far as that goes, this is 'expected'. Can you still boot Windows from the EFI boot manager, however your firmware makes it available?

Comment 5 Adam Williamson 2013-06-06 17:24:52 UTC
Oh, I don't think your issue is the same as Vasilis' - I think in F18 we had a general bug which meant UEFI installs would never put a 'boot Windows' entry in their grub2 config (at the time I didn't think that was necessarily a bug, but now I do). Vasilis' bug is a dupe of some other one which we fixed at some point during F19 cycle, I'll look for that.

Comment 6 A.J. Werkman 2013-06-06 18:25:54 UTC
(In reply to Adam Williamson from comment #4)
> I don't think it's possible for a BIOS install of Fedora (or any Linux) to
> 'chainload' a UEFI install of Windows; once you get to grub2 you're already
> in 'BIOS compatibility mode' and there's no way you could break out into
> 'UEFI mode'. AIUI anyhow. So as far as that goes, this is 'expected'. Can
> you still boot Windows from the EFI boot manager, however your firmware
> makes it available?

FYI I have this issue on a Intel DH77KC motherboard. In my Bios I only have one option "UEFI Boot" which I set to enabled.

Furthermore nor in Windows installation nor in Fedora installation I made a deliberate choice wether to install in EFI or BIOS mode. For the test I blanked the first few sectors of the harddisk with dd. Then I put in the W8 CD, hit the reset button and let it boot. I assigned it 60Gb of the total of 240Gb of disk space. W8 setup a few partitions and ended installation without failure. After that I booted PXE and installed F19TC1 almost without specific user choices. From this I expect W8 to be installed in EFI and F19 to be installed in BIOS mode.

In this situation I can request the boot menu of the bios/EFI by hitting F10. This gives me a choice between my harddisk, DVD drive and an item 'Windows Boot Manager' which I presume is the EFI boot entry for W8. But selecting this, does not result in booting W8. It actually gives no respons at all. Selecting the harddisk fires up grub as expected, but as I said without a windows entry.

I don't see any other possibilties to boot an EFI boot manager.

Comment 7 Chris Murphy 2013-06-06 19:24:44 UTC
Adding Mads for his perspective. I don't think this is an anaconda bug, it might be a grub2 bug or rfe, but I don't know if it's a given that once the UEFI CSM is loaded, if it's possible for GRUB BIOS to have UEFI back out the CSM, and boot an arbitrary OS.

Also, there has been some work for GRUB EFI to support PXE booting, but I don't know the state of that work. I'd say the PXE installation of Fedora, if it's non-UEFI, isn't that useful. Typically the CSM doesn't provide full AHCI and ACPI support so things like SSDs aren't as fast (fall back to IDE mode), and if it's a laptop the battery life is poor. So I'd find an alternative installation, e.g. netinst.iso.

Comment 8 Adam Williamson 2013-06-07 17:16:18 UTC
A.J: whether you are running UEFI or 'BIOS' (same thing as 'CSM', in case you're confused) mode is a choice made at boot time. No OS installer can offer this option because by the time you reach the OS installer, the decision has been made. Which mode you boot in is something you choose, ultimately, via the system firmware in some way; it is difficult to be more specific than this because different firmware implementations offer it in very different ways.

On your system it sounds like you just have a 'universal switch' for UEFI mode: if you have that ON and boot a UEFI-capable medium I expect it will boot in UEFI mode. (I suspect it would fall back transparently to BIOS/CSM mode if you try to boot a non-UEFI-capable medium with that switch set to ON, though).

Yes, we are well aware this is a giant, complicated pain in the ass. We wish it weren't, believe me.

I think your assessment of your situation is correct, and it's obviously worrying that you can do a BIOS install of Fedora to a disk that already contains a UEFI install of Windows and after that, it seems, the Windows install fails to boot correctly. But I don't have the detailed knowledge to evaluate the state you've wound up in precisely, so I don't want to go further than that. As Chris says, we really need an expert to take a look at this and sort it out. He CCed Mads, I'm CCing mjg59 :)

Comment 9 Adam Williamson 2013-06-07 17:21:09 UTC
There is some information available from test@ on this bug as well. In particular, the efibootmgr output after the Fedora install:

Booted F19TC1 rescue in EFI mode.

The output of efibootmgr --verbose is:

BootCurrent: 0007
Timeout: 1 seconds
BootOrder: 0000,0007,0008,0005,0003,0006,0004
Boot0000* Windows Boot Manager    HD(2,96800,31800,06701451-3ec2-4b01-8dac-17f25a3c6bd4)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot0003* SanDisk SDSSDH2256G    BIOS(2,0,00)AMBO
Boot0004* IBA GE Slot 00C8 v1381    BIOS(6,0,00)AMBO
Boot0005* TSSTcorp CDDVDW SH-S223C    BIOS(3,0,00)AMBO
Boot0006* hp v135w 0.00    BIOS(2,0,00)AMBO
Boot0007* UEFI: TSSTcorp CDDVDW SH-S223C    ACPI(a0341d0,0)PCI(1f,2)03120a000200ffff0000CD-ROM(1,8309,2fac)AMBO
Boot0008* UEFI: TSSTcorp CDDVDW SH-S223C    ACPI(a0341d0,0)PCI(1f,2)03120a000200ffff0000Vendor(ba7c46d1-9c5e-4fc8-943d-1a491f23fe01,c2770200000277c222001d0000000000001d0008000000000800450c1f130000ec0200000100000101004665646f72612031392d544331207838365f3634202020202020202020202020)AMBO
Boot000A* SanDisk SDSSDH2256G    BIOS(2,0,00)AMBO

Comment 10 Adam Williamson 2013-06-07 18:07:05 UTC
So, I talked to a couple of the experts (pjones and mjg59) about this issue.

Their evaluation is that, in all likelihood, Fedora has not done anything wrong here, and ultimately the issue is a bug in the Intel firmware: it fails to boot a native UEFI install of Windows if the disk it's on contains an MBR (from the Fedora install).

There's a few things we can do to check this evaluation. Can you please provide a listing of the contents of the EFI system partition - which should be a fairly small FAT32 partition at or near the start of the drive? That is the partition which the Windows Boot Manager boot entry should be referring to: obviously, we need to be sure the file EFI\Microsoft\Boot\bootmgfw.efi exists, and other things we might expect to find there.

The output of 'gdisk -l /dev/sda' (or whatever the disk actually is) would also be useful.

Comment 11 Chris Murphy 2013-06-07 18:34:04 UTC
Could we also get clarification from the bug reporter that Windows is in fact not bootable; that using his firmware's boot manager to choose Windows is actually broken?

The way I read the bug description, the report expects a GRUB menu entry for Windows, not that the installation of Fedora has broken the bootability of Windows.

Comment 12 A.J. Werkman 2013-06-07 21:42:33 UTC
Created attachment 758346 [details]
Listing of /dev/sda2

Comment 13 Adam Williamson 2013-06-07 21:44:01 UTC
Chris: read the later posts, this is why I changed the summary.

"In this situation I can request the boot menu of the bios/EFI by hitting F10. This gives me a choice between my harddisk, DVD drive and an item 'Windows Boot Manager' which I presume is the EFI boot entry for W8. But selecting this, does not result in booting W8. It actually gives no respons at all. Selecting the harddisk fires up grub as expected, but as I said without a windows entry."

Comment 14 Adam Williamson 2013-06-07 21:44:44 UTC
aj: can we get the gdisk output also? Thanks.

Comment 15 A.J. Werkman 2013-06-07 21:50:34 UTC
Collided with your post, but here it is;-)

As for comment #11: I can confirm, that so far I have not been able to boot Win 8 after installation of Fedora. Altough I still have an entry 'Windows Boot Manager' in the one-time boot menu of the bios. But selecting this just brings me back in the boot menu after a little flickering of the screen.

(In reply to Adam Williamson from comment #10)
 
> There's a few things we can do to check this evaluation. Can you please
> provide a listing of the contents of the EFI system partition - which should
> be a fairly small FAT32 partition at or near the start of the drive? That is
> the partition which the Windows Boot Manager boot entry should be referring
> to: obviously, we need to be sure the file EFI\Microsoft\Boot\bootmgfw.efi
> exists, and other things we might expect to find there.
> 
> The output of 'gdisk -l /dev/sda' (or whatever the disk actually is) would
> also be useful.

The listing of /dev/sda2 is in the attachment.

gdisk -l /dev/sda gives:
GPT fdisk (gdisk) version 0.8.6

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 500118192 sectors, 238.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 2C961F7A-2D66-4F59-B827-71A2D3FF151E
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 500118158
Partitions will be aligned on 2048-sector boundaries
Total free space is 2669 sectors (1.3 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          616447   300.0 MiB   2700  Basic data partition
   2          616448          819199   99.0 MiB    EF00  EFI system partition
   3          819200         1081343   128.0 MiB   0C01  Microsoft reserved part
   4         1081344       122879999   58.1 GiB    0700  Basic data partition
   5       122880000       122882047   1024.0 KiB  EF02  
   6       122882048       123906047   500.0 MiB   0700  
   7       123906048       140306431   7.8 GiB     8200  
   8       140306432       245164031   50.0 GiB    0700  
   9       245164032       500117503   121.6 GiB   0700

Comment 16 Matthew Garrett 2013-06-07 21:57:23 UTC
We haven't modified the EFI system partition, we haven't modified the EFI boot variables and we don't appear to have screwed with the partition table in a way that would result in it failing. I'm not sure what else we could have done here.

Comment 17 Chris Murphy 2013-06-07 22:18:39 UTC
Use gdisk to delete the partitions in reverse order, attempting to boot the Windows entry from the firmware (F10 menu) between each deletion. I wonder if either the firmware or the Windows EFI boot loader is confused by the presence of the EF02 or one of the 0700 entries.

Partitions 6, 8, 9 are set to a non-Linux specific GUID used for Windows basic data. A Linux specific GUID was proposed and patched in parted with this commit:
http://git.savannah.gnu.org/cgit/parted.git/commit/?id=e6536360bd4496cee1f1bf2dfb0b11f6bdbbfd4b

Comment 18 Adam Williamson 2013-06-08 00:11:26 UTC
Chris' idea is a good one, and if that doesn't fly, we might want you to zero out the MBR area on the disk and see if *that* makes it fly (someone please yell if that's a bad idea).

Comment 19 Chris Murphy 2013-06-08 00:30:20 UTC
(In reply to Adam Williamson from comment #18)
That's also a good thing to try, although it should be ignored by the firmware except via a CSM. Key word should. A safe way to remove it is 'sudo dd if=/dev/zero of=/dev/sdX bs=440 count=1' which will remove the code but not the PMBR. I'd try this independently of other changes, to isolate this. The code is easily replaced should it be desired, but there are enough drawbacks to CSM mode boot I'd use it as a last resort.

Comment 20 Adam Williamson 2013-06-08 00:32:44 UTC
"Key word should"

or as kparal calls it, 'the s word' :)

we've already pretty much established the firmware isn't behaving as it 'should'; it's just question of narrowing down exactly what it's doing wrong...

Comment 21 A.J. Werkman 2013-06-08 09:06:31 UTC
(In reply to Chris Murphy from comment #19)
> (In reply to Adam Williamson from comment #18)
> That's also a good thing to try, although it should be ignored by the
> firmware except via a CSM. Key word should. A safe way to remove it is 'sudo
> dd if=/dev/zero of=/dev/sdX bs=440 count=1' which will remove the code but
> not the PMBR. I'd try this independently of other changes, to isolate this.
> The code is easily replaced should it be desired, but there are enough
> drawbacks to CSM mode boot I'd use it as a last resort.

I deleted the partitions one at the time and did a boot attempt on the windows manager from the firmware. But this failed every instance. Then with the deleted partition I zerod the MBR as givven above and tried the windows boot, which again failed.

Next I completly wiped the disk, reinstalled Windows, verified the ablity to boot from the firmware boot item, reinstalled Fedora, verified that windows is not bootable anymore. From this situation I zerod the MBR and found that windows is again not bootable from the firmware.

Looks like cleaning out the partitions and wiping the MBR does not bring my system back in exactly the state it was in immediatly after the Win8 was installed.

Probably expected, but the partial zeroing of the MRB makes booting into grub impossible.

Comment 22 Chris Murphy 2013-06-08 11:50:44 UTC
When you say "completely wiped" what does that mean exactly? Some sort of state change is occurring as a result of Fedora being installed that makes the firmware (or the Windows bootloader) disagreeable. Either by wiping the disk, or by reinstalling Windows, the proper state is restored. But what? If not MBR code or partitions, then it seems it must be NVRAM.

Does the confusion occur merely by booting a legacy OS, causing the firmware to fallback with the CSM? Or is actual installation of Fedora necessary to cause this problem? I'm curious what the NVRAM contents are at these stages:
1. wiped disk, fresh installed and working Windows.
2. PXE boot Fedora, but not installed (just restart after getting to the installer)
3. PXE boot Fedora, installed

Comment 23 Chris Murphy 2013-06-08 11:52:27 UTC
If it's not obvious, to get the NVRAM contents for 1, 2 and 3, A.J. needs to EFI boot linux, as in comment 9.

Comment 24 A.J. Werkman 2013-06-08 16:30:29 UTC
(In reply to Chris Murphy from comment #22)
> When you say "completely wiped" what does that mean exactly? Some sort of
> state change is occurring as a result of Fedora being installed that makes
> the firmware (or the Windows bootloader) disagreeable. Either by wiping the
> disk, or by reinstalling Windows, the proper state is restored. But what? If
> not MBR code or partitions, then it seems it must be NVRAM.
With comletely wiped I mean:
dd if=/dev/zero bs=1024k count=10 of=/dev/sda
And as I don't know how to dd the GPT to zero I used gdisk to clear all the GPT partition entries.
 
> I'm curious what the NVRAM contents are at these stages:
> 1. wiped disk, fresh installed and working Windows.
> 2. PXE boot Fedora, but not installed (just restart after getting to the
> installer)
> 3. PXE boot Fedora, installed

After step 1 W8 is bootable, After step two W8 is bootable and after step 3 W8 is not bootable.

The difference I see is how fdisk -l show a compleet different output in step 1/2 and after step 3. Looks like the Fedora installation has done some changes here.


Case1/fdisk-l.txt
=======================================================

Disk /dev/sda: 256.1 GB, 256060514304 bytes, 500118192 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1  4294967295  2147483647+  ee  GPT
=======================================================
Case2/fdisk-l.txt
=======================================================

Disk /dev/sda: 256.1 GB, 256060514304 bytes, 500118192 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1  4294967295  2147483647+  ee  GPT
=======================================================
Case3/fdisk-l.txt
=======================================================

Disk /dev/sda: 256.1 GB, 256060514304 bytes, 500118192 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt


#         Start          End    Size  Type            Name
 1         2048       616447    300M  Windows recover Basic data partition
 2       616448       819199     99M  EFI System      EFI system partition
 3       819200      1081343    128M  Microsoft reser Microsoft reserved partition
 4      1081344    122879999   58.1G  Microsoft basic Basic data partition
 5    122880000    122882047      1M  BIOS boot parti 
 6    122882048    123906047    500M  Microsoft basic 
 7    123906048    140306431    7.8G  Linux swap      
 8    140306432    245164031     50G  Microsoft basic 
 9    245164032    500117503  121.6G  Microsoft basic 
=======================================================
Case1/gdisk-l.txt
=======================================================
GPT fdisk (gdisk) version 0.8.6

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 500118192 sectors, 238.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): A840F3D1-007B-49AF-802D-61807250393C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 500118158
Partitions will be aligned on 2048-sector boundaries
Total free space is 377240173 sectors (179.9 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          616447   300.0 MiB   2700  Basic data partition
   2          616448          819199   99.0 MiB    EF00  EFI system partition
   3          819200         1081343   128.0 MiB   0C01  Microsoft reserved part
   4         1081344       122879999   58.1 GiB    0700  Basic data partition
=======================================================
Case2/gdisk-l.txt
=======================================================
GPT fdisk (gdisk) version 0.8.6

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 500118192 sectors, 238.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): A840F3D1-007B-49AF-802D-61807250393C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 500118158
Partitions will be aligned on 2048-sector boundaries
Total free space is 377240173 sectors (179.9 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          616447   300.0 MiB   2700  Basic data partition
   2          616448          819199   99.0 MiB    EF00  EFI system partition
   3          819200         1081343   128.0 MiB   0C01  Microsoft reserved part
   4         1081344       122879999   58.1 GiB    0700  Basic data partition
=======================================================
Case3/gdisk-l.txt
=======================================================
GPT fdisk (gdisk) version 0.8.6

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 500118192 sectors, 238.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): A840F3D1-007B-49AF-802D-61807250393C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 500118158
Partitions will be aligned on 2048-sector boundaries
Total free space is 2669 sectors (1.3 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          616447   300.0 MiB   2700  Basic data partition
   2          616448          819199   99.0 MiB    EF00  EFI system partition
   3          819200         1081343   128.0 MiB   0C01  Microsoft reserved part
   4         1081344       122879999   58.1 GiB    0700  Basic data partition
   5       122880000       122882047   1024.0 KiB  EF02  
   6       122882048       123906047   500.0 MiB   0700  
   7       123906048       140306431   7.8 GiB     8200  
   8       140306432       245164031   50.0 GiB    0700  
   9       245164032       500117503   121.6 GiB   0700  
=======================================================
Case1/efi.txt
=======================================================
BootCurrent: 0006
Timeout: 1 seconds
BootOrder: 0000,0006,0007,0005,0003,0004
Boot0000* Windows Boot Manager	HD(2,96800,31800,8c4fa9d5-5be8-41f6-942f-afc145397f1c)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...6................
Boot0003* SanDisk SDSSDH2256G	BIOS(2,0,00)AMBO
Boot0004* IBA GE Slot 00C8 v1381	BIOS(6,0,00)AMBO
Boot0005* TSSTcorp CDDVDW SH-S223C	BIOS(3,0,00)AMBO
Boot0006* UEFI: TSSTcorp CDDVDW SH-S223C	ACPI(a0341d0,0)PCI(1f,2)03120a000200ffff0000CD-ROM(1,8309,2fac)AMBO
Boot0007* UEFI: TSSTcorp CDDVDW SH-S223C	ACPI(a0341d0,0)PCI(1f,2)03120a000200ffff0000Vendor(ba7c46d1-9c5e-4fc8-943d-1a491f23fe01,c2770200000277c222001d0000000000001d0008000000000800450c1f130000ec0200000100000101004665646f72612031392d544331207838365f3634202020202020202020202020)AMBO
Boot000A* SanDisk SDSSDH2256G	BIOS(2,0,00)AMBO
=======================================================
Case2/efi.txt
=======================================================
BootCurrent: 0006
Timeout: 1 seconds
BootOrder: 0000,0006,0007,0005,0003,0008,0004
Boot0000* Windows Boot Manager	HD(2,96800,31800,8c4fa9d5-5be8-41f6-942f-afc145397f1c)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...6................
Boot0003* SanDisk SDSSDH2256G	BIOS(2,0,00)AMBO
Boot0004* IBA GE Slot 00C8 v1381	BIOS(6,0,00)AMBO
Boot0005* TSSTcorp CDDVDW SH-S223C	BIOS(3,0,00)AMBO
Boot0006* UEFI: TSSTcorp CDDVDW SH-S223C	ACPI(a0341d0,0)PCI(1f,2)03120a000200ffff0000CD-ROM(1,8309,2fac)AMBO
Boot0007* UEFI: TSSTcorp CDDVDW SH-S223C	ACPI(a0341d0,0)PCI(1f,2)03120a000200ffff0000Vendor(ba7c46d1-9c5e-4fc8-943d-1a491f23fe01,c2770200000277c222001d0000000000001d0008000000000800450c1f130000ec0200000100000101004665646f72612031392d544331207838365f3634202020202020202020202020)AMBO
Boot0008* hp v135w 0.00	BIOS(2,0,00)AMBO
Boot000A* SanDisk SDSSDH2256G	BIOS(2,0,00)AMBO
=======================================================
Case3/efi.txt
=======================================================
BootCurrent: 0006
Timeout: 1 seconds
BootOrder: 0000,0006,0007,0005,0003,0008,0004
Boot0000* Windows Boot Manager	HD(2,96800,31800,8c4fa9d5-5be8-41f6-942f-afc145397f1c)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...6................
Boot0003* SanDisk SDSSDH2256G	BIOS(2,0,00)AMBO
Boot0004* IBA GE Slot 00C8 v1381	BIOS(6,0,00)AMBO
Boot0005* TSSTcorp CDDVDW SH-S223C	BIOS(3,0,00)AMBO
Boot0006* UEFI: TSSTcorp CDDVDW SH-S223C	ACPI(a0341d0,0)PCI(1f,2)03120a000200ffff0000CD-ROM(1,8309,2fac)AMBO
Boot0007* UEFI: TSSTcorp CDDVDW SH-S223C	ACPI(a0341d0,0)PCI(1f,2)03120a000200ffff0000Vendor(ba7c46d1-9c5e-4fc8-943d-1a491f23fe01,c2770200000277c222001d0000000000001d0008000000000800450c1f130000ec0200000100000101004665646f72612031392d544331207838365f3634202020202020202020202020)AMBO
Boot0008* hp v135w 0.00	BIOS(2,0,00)AMBO
Boot000A* SanDisk SDSSDH2256G	BIOS(2,0,00)AMBO
=======================================================

Comment 25 Chris Murphy 2013-06-08 21:35:06 UTC
fdisk -l on my gpt system reports both the MBR and the GPT, with a line separating the two listings as "WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion."

In your case it appears to report only MBR for Case 1 and Case 2, and only GPT for case 3. Is that correct, or is the full listing mistakenly omitted? We need to figure out what's different between case1/2 and case 3. It's not NVRAM. There's an additional boot item (Boot0008) that appears just by PXE booting Fedora in case 2, but that didn't prevent Windows from booting.

Comment 26 A.J. Werkman 2013-06-09 13:22:03 UTC
(In reply to Chris Murphy from comment #25)
> fdisk -l on my gpt system reports both the MBR and the GPT, with a line
> separating the two listings as "WARNING: fdisk GPT support is currently new,
> and therefore in an experimental phase. Use at your own discretion."
> 
> In your case it appears to report only MBR for Case 1 and Case 2, and only
> GPT for case 3. Is that correct, or is the full listing mistakenly omitted?

I redirected the fdisk output directly to file, so what you see is what was reported by fdisk. Ie 1/2 only MBR and 3 only gpt.


> We need to figure out what's different between case1/2 and case 3. It's not
> NVRAM. There's an additional boot item (Boot0008) that appears just by PXE
> booting Fedora in case 2, but that didn't prevent Windows from booting.

I think this extra boot item was the USB-stick that I wrote the output to. I didn't connect it right away, so you won't find it in all BIOS detection schemes.

Comment 27 Chris Murphy 2013-06-09 16:13:48 UTC
Weird fdisk behavior. Let's take a look at the raw data instead for Case 1 and Case 3, you can skip case 2. So wipe the disk again, reinstall Windows, and make sure it's bootable and then boot from Linux Live media and use:

dd if=/dev/sdX count=4 of=postwindows.bin

Then install Fedora, confirm Windows isn't bootable, then boot from Linux Live media and use:

dd if=/dev/sdX count=4 of=postfedora.bin

I suggest attaching the two files to the bug report, rather than pasting the data as a comment. The four sectors will contain the MBR, GPT primary header, and GPT primary tables.

Comment 28 A.J. Werkman 2013-06-09 18:22:13 UTC
Created attachment 758891 [details]
Postwindows

SHA256 checksums:

9858783b43d8ebd47b75581e8099f2b066fb853e0a5d7c82a2d809da58b3ddc9  postfedora.bin
713b6744fe45d642665dc476e6d2530173b7e0d7c27689a495b48eb225da7b35  postwindows.bin

Comment 29 A.J. Werkman 2013-06-09 18:23:05 UTC
Created attachment 758892 [details]
Postfedora

Comment 30 Chris Murphy 2013-06-09 21:18:04 UTC
Windows UEFI is writing boot loader code to the MBR. That's weird. It's not just your firmware that sees a difference with MBR/GPT, fdisk behaves differently after  Fedora is installed also. It could mean there's a parted bug inducing this.

Comment 31 Rod Smith 2013-06-10 00:29:07 UTC
I've examined the postwindows.bin and postfedora.bin files using an older version of fdisk that lacks all GPT support, so as to view the true MBR contents. Here's what I get:

$ fdisk -l postwindows.bin 
You must set cylinders.
You can do this from the extra functions menu.

WARNING: GPT (GUID Partition Table) detected on 'postwindows.bin'! The util fdisk doesn't support GPT. Use GNU Parted.


Disk postwindows.bin: 0 MB, 2048 bytes, 4 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

          Device Boot      Start         End      Blocks   Id  System
postwindows.bin1               1  4294967295  2147483647+  ee  GPT

$ fdisk -l postfedora.bin 
You must set cylinders.
You can do this from the extra functions menu.

WARNING: GPT (GUID Partition Table) detected on 'postfedora.bin'! The util fdisk doesn't support GPT. Use GNU Parted.


Disk postfedora.bin: 0 MB, 2048 bytes, 4 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

         Device Boot      Start         End      Blocks   Id  System
postfedora.bin1   *           1   500118191   250059095+  ee  GPT

I see two differences, at least at this level of analysis (there may be other, more subtle, differences not revealed by fdisk):

- The end sector has changed, from 4,294,967,295 to 500,118,191. Since the
  former value is (2^32 - 1), it's likely to be spurious unless the disk is
  over 2TiB in size. Thus, the change is probably valid; however, if the disk
  is over 2TiB in size, the change could be a bug in libparted, and it
  could be the cause of the problem.

- The postwindows output shows that the 0xEE protective partition is NOT
  set as bootable, as per the EFI spec; however, the Fedora installer seems
  to have set the 0xEE protective partition's boot flag. This is a violation
  of the EFI spec, although it's one that's harmless on most systems.

My suspicion is that setting the protective partition as active is the cause of the problem. You should be able to use an OLDER version of fdisk to undo this change. (Use a Linux emergency disc to do this, if necessary.) If that doesn't fix the problem and if the disk is over 2TiB in size, them perhaps creating a fresh protective MBR with gdisk ("x" followed by "n" followed by "w") will correct the problem. (This should also wipe the "boot flag" from the 0xEE partition.)

Comment 32 Rod Smith 2013-06-10 02:53:34 UTC
Some more points:

- Getting EFI-mode and BIOS-mode installations to coexist can be tricky
  on any motherboard, but it's trickier on some than on others. Some
  boards (including at least some Intel boards) require the boot/active
  flag to be set on at least one MBR partition in order to boot in BIOS
  mode. If this flag being set also interferes with the ability to boot
  an OS in EFI mode, coexistence of BIOS-mode and EFI-mode OSes may be
  impossible on such a computer.

- On some computers, rEFInd can redirect from an EFI-mode boot to a
  BIOS-mode boot. In theory, this enables an EFI-mode Windows and a
  BIOS-mode Linux to coexist. In practice, I'm not sure this will work
  on A.J. Werkman's computer because of its finicky Intel firmware.
  Note that an adjustment to the "scanfor" line in rEFInd's configuration
  file is required to boot a BIOS-based OS on a PC.

- The best solution to the problem in the short term is to either
  install Fedora in EFI mode or to install an EFI-mode boot loader for
  Linux (correcting whatever the cause of the EFI-mode boot problem is).

- IMHO, the Fedora installer needs to do a better job of detecting when
  it's running in a boot mode that's incompatible with the Windows boot
  mode. Since the latter is predictable based on the partition table
  type, this task is easy, and an appropriate action could be taken.

Comment 33 Chris Murphy 2013-06-10 03:17:35 UTC
(In reply to Rod Smith from comment #32)
> - IMHO, the Fedora installer needs to do a better job of detecting when
>   it's running in a boot mode that's incompatible with the Windows boot
>   mode.

A.J. could you use parted's print command to confirm the Disk Flags is pmbr_boot, then use command 'disk_toggle pmbr_boot' to remove the flag, and see if Windows is now bootable?

If it does fix the problem, either anaconda needs to warn the user that a BIOS mode installation could break the bootability of Windows; or we need an exception to setting pmbr_boot on UEFI PC's with Windows EFI installed. This exception is in place for EFI Macs:
http://www.redhat.com/archives/anaconda-devel-list/2012-February/msg00124.html

Comment 34 Chris Murphy 2013-06-10 03:25:34 UTC
If A.J. confirms the work around, this bug skims very closely to the current final release criteria #9:"The installer must ... either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working." The installer doesn't directly touch the bootloader but may be indirectly breaking it by setting a flag on the PMBR that the firmware isn't expecting.

Comment 35 A.J. Werkman 2013-06-10 06:23:29 UTC
(In reply to Chris Murphy from comment #33)
> A.J. could you use parted's print command to confirm the Disk Flags is
> pmbr_boot, then use command 'disk_toggle pmbr_boot' to remove the flag, and
> see if Windows is now bootable?
> 

That does the trick!

pmbr_boot was set. When I unset it, w8 booted again.


Model: ATA SanDisk SDSSDH22 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: pmbr_boot

Number  Start   End     Size    File system     Name                          Flags
 1      1049kB  316MB   315MB   ntfs            Basic data partition          hidden, diag
 2      316MB   419MB   104MB   fat32           EFI system partition          boot
 3      419MB   554MB   134MB                   Microsoft reserved partition  msftres
 4      554MB   62.9GB  62.4GB  ntfs            Basic data partition
 5      62.9GB  62.9GB  1049kB                                                bios_grub
 6      62.9GB  63.4GB  524MB   ext4
 7      63.4GB  71.8GB  8397MB  linux-swap(v1)
 8      71.8GB  126GB   53.7GB  ext4
 9      126GB   256GB   131GB   ext4

Comment 36 Adam Williamson 2013-06-10 07:54:25 UTC
Nice detective work, Chris and Rod! Matthew, Peter, do you think this is incorrect behaviour on the installer's behalf, or a bug in the Intel firmware, or both? I seem to recall vaguely that we've discussed this issue (setting the pmbr_boot flag) before - possibly in relation to the Mac scenario Chris mentions above - but my memory is a bit murky.

Comment 37 Matthew Garrett 2013-06-10 13:21:46 UTC
BIOS installs on GPT will often fail if this flag isn't set. There's no good answer here.

Comment 38 Chris Murphy 2013-06-10 13:25:11 UTC
Better to warn or even blindly refuse to install than to blindly break the prior (likely primary) OS.

Comment 39 Matthew Garrett 2013-06-10 13:35:56 UTC
Well, that's part of the problem - detecting this case isn't straightforward.

Comment 40 Adam Williamson 2013-06-10 16:35:37 UTC
well, per another bug currently under discussion, don't we already have code to detect an existing UEFI windows install in os-prober? Can we use that?

Comment 41 Matthew Garrett 2013-06-10 16:42:11 UTC
They only run on EFI systems.

Comment 42 Rod Smith 2013-06-10 17:29:43 UTC
How about this:

if (Installer_booted_in_BIOS_mode) {
   if (GPT_detected) {
      // OK for Linux, but not for Windows
      if (Windows_detected) {
         // GPT & Windows means EFI-mode boot of Windows, despite
         // BIOS-mode boot of Fedora installer!
         clear_PMBR_boot_flag();
         warn_user("Incompatible Windows and Linux boot modes");
         // Optionally abort the installation.
         // Alternatively, could rename the Windows boot loader and
         // put the Fedora EFI-mode boot loader in its place. This is
         // an ugly hack, but it usually works.
      } else { // No Windows
         // OK to do what we want, *BUT* user might subsequently
         // want to install Windows, so user should be warned
         set_PMBR_boot_flag();
         warn_user("future Windows installs will be difficult");
      }
   }
   Install_BIOS_mode_bootloader();
} else { // installer booted in EFI mode
   if (GPT_detected) {
      // Apparently a normal EFI-bootable system....
      clear_PMBR_boot_flag();
      Install_EFI_mode_bootloader();
   } else { // MBR detected
      // Weird setup at best
      if (Windows_detected) {
         // Windows MUST be booting in BIOS mode....
         warn_user("Presumed BIOS-mode Windows installation; installing BIOS bootloader, despite EFI-mode boot");
         Install_BIOS_mode_bootloader();
      } else {
         warn_user("EFI-mode boot with MBR on boot disk");
         abort_installation(); // or could install a BIOS-mode boot loader
      }
   }
}

I haven't studied the Anaconda code, so this pseudo-code might need to be split up or otherwise significantly changed. Obviously, this pseudo-code assumes that flags for the partition table type (GPT_detected), the boot mode (Installer_booted_in_BIOS_mode), and the presence of a Windows installation (Windows_detected) have already been set. It assumes the partition table already exists, so on a blank disk that must already have been done when this code executes. It requires user understanding, or enough of an explanation of the nature of the problem in the warnings, so that users can make reasonably informed decisions at install time. The warn_user() function would presumably give users the option to abort, or possibly to select from multiple different actions. Key points are:

- These conditionals detect potentially troublesome mismatches -- an EFI-mode
  install on an MBR disk and a BIOS-mode install on a GPT disk are both
  unusual at best, and signs of a train wreck waiting to happen on a system
  that dual-boots with Windows.
- The user is warned of potential problems.
- The boot loader installed is adjusted when possible.

IMHO, Anaconda should also explicitly tell the user which installation mode is being used, even if a problem isn't detected. This information needn't be obtrusive, but it should be obvious.

Comment 43 Chris Murphy 2013-06-11 02:17:37 UTC
(In reply to Matthew Garrett from comment #37)
There's a continuum here, and presently it's at the definitely not good end. Arguably the BIOS install is unintended due to a combination of user confusion, and the firmware and installer making BIOS installs too easy. The user isn't flagged or warned at all. And the end result is the existing system isn't bootable.

Comment 44 Keshav Amburay 2013-08-30 18:35:09 UTC
There are a few ways to detect whether Windows is booting in BIOS mode or UEFI mode:

1. Windows bootmgr and BCD are stores in a NTFS formatted "SYSTEM" partition (which may or may not be C:, similar to "/" vs "/boot") in case of BIOS boot from a fixed disk. In case UEFI boot those files are always stored in the FAT 32/16 formatted EFI System Partition.

2. For BIOS boot, bootmgr is present in the root of the "SYSTEM" partition (ie /bootmgr) while BCD is located at /Boot/BCD (case-insensitive AFAIK). For UEFI boot they are located as /EFI/Microsoft/Boot/{bootmgr.efi,bootmgfw.efi,BCD}  (actually bootmgfw.efi does the equivalent work of /bootmgr, not bootmgr.efi)

3. The BCD file itself contains the final clue and probably the most effective way of detecting whether Windows is booting via BIOS or UEFI. The job of bootmgr or bootmgfw.efi is to launch the "winload" file from actual C: . In case of BIOS C:\windows\system32\winload.exe is launched while in case of UEFI \windows\system32\winload.efi (note the file extension difference). So the most effective way to detect is by using hivexml (http://libguestfs.org/hivex.3.html)

hivexml <path to BCD> | grep 'winload.efi' 1> /dev/null
hivexml <path to BCD> | grep 'winload.exe' 1> /dev/null

Irrespective of BIOS or UEFI boot, Windows copies BIOS bootmgr to C:\bootmgr, so the presence of C:\bootmgr alone does not give us any indication about Windows boot mode. Hope this helps.

Comment 45 Orion Poplawski 2013-09-24 15:25:16 UTC
I think I'm seeing something similar in bug #1011252, but in this case it appears to be a BIOS booted Windows 7 install on a GPT disk.  The firmware config on the laptop indicates a Legacy BIOS boot and fails if I change it to UEFI (no valid signature).  If I toggle the disk pmbr_boot flag I can get back to Windows 7.  There is no bootmgr present in the Windows 7 partitions.

Comment 46 Chris Murphy 2013-09-24 15:39:03 UTC
(In reply to Orion Poplawski from comment #45)
Windows 7 will not boot from a GPT disk on BIOS hardware. On BIOS hardware Windows requires MBR partition scheme. On UEFI hardware Windows requires GPT partition scheme.

There is no good way to combine multiboot BIOS and UEFI OS's on the same machine.

Comment 47 Orion Poplawski 2013-09-25 14:41:08 UTC
*** Bug 1011252 has been marked as a duplicate of this bug. ***

Comment 48 Rod Smith 2013-10-12 22:02:05 UTC
Regarding Chris Murphy's comment that "there is no good way to combine multiboot BIOS and UEFI OS's on the same machine," I disagree. Some EFI boot managers enable making the switch with relative ease, although you do generally have to hit a key at boot time to access the boot manager. Because the key to press varies so much, though, and the capability is not always present, this isn't really something that applies across the board. Still, it's an option for some users.

A method that works on more computers is to employ my rEFInd (http://www.rodsbooks.com/refind/). This software includes the ability to redirect the boot process from EFI mode to BIOS/CSM/legacy mode. Thus, in the situation that triggered this bug report, rEFInd might be a solution. There are some important caveats, though:

- rEFInd's default configuration does NOT activate BIOS/CSM/legacy support on
  UEFI-based PCs, just on Macs. Editing refind.conf to uncomment the "scanfor"
  line and add "hdbios" to the list of options is required.
- Some EFIs don't include CSM support. This can be true even on some computers
  that can boot in BIOS mode, such as systems based on Gigabyte's "Hybrid EFI."
  Thus, this solution is not universal, although it will work on most systems
  that ship with Windows 8, judging by forum posts I've seen.
- rEFInd's CSM support is still limited. In particular, it can usually boot
  from the first hard disk, but not the second or subsequent disk. Thus, care
  must be taken in placing the BIOS-mode boot loader.
- As a practical matter, once rEFInd is installed, it's likely to be easier to
  do a direct EFI-mode boot of Linux than to boot through a BIOS-mode version
  of GRUB. (OTOH, some computers have video or other hardware problems when
  booted in EFI mode, so sometimes mixing modes via rEFInd is the best way
  to get the system running.)
- rEFInd's CSM support requires compiling rEFInd with the Tianocore EDK2
  rather than GNU-EFI. My own official binaries are built with Tianocore, so
  this isn't a problem when using them. Some distributions (such as ALT Linux)
  provide rEFInd binaries built with GNU-EFI, so this fix wouldn't work with
  them.

The bottom line is that EFI/BIOS-mode solutions can be quite workable under certain conditions, albeit not universally.

Comment 49 David Shea 2013-11-07 21:29:34 UTC
*** Bug 1027624 has been marked as a duplicate of this bug. ***

Comment 50 Fedora End Of Life 2015-01-09 18:20:34 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 51 Fedora End Of Life 2015-02-17 15:28:34 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.