Red Hat Bugzilla – 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
Last modified: 2015-02-17 10:28:34 EST
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.
Please check if this bug helps you at all: https://bugzilla.redhat.com/show_bug.cgi?id=873207
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.
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.
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?
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.
(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.
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.
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 :)
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
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.
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.
Created attachment 758346 [details] Listing of /dev/sda2
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."
aj: can we get the gdisk output also? Thanks.
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
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.
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
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).
(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.
"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...
(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.
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
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.
(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 =======================================================
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.
(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.
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.
Created attachment 758891 [details] Postwindows SHA256 checksums: 9858783b43d8ebd47b75581e8099f2b066fb853e0a5d7c82a2d809da58b3ddc9 postfedora.bin 713b6744fe45d642665dc476e6d2530173b7e0d7c27689a495b48eb225da7b35 postwindows.bin
Created attachment 758892 [details] Postfedora
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.
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.)
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.
(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
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.
(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
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.
BIOS installs on GPT will often fail if this flag isn't set. There's no good answer here.
Better to warn or even blindly refuse to install than to blindly break the prior (likely primary) OS.
Well, that's part of the problem - detecting this case isn't straightforward.
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?
They only run on EFI systems.
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.
(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.
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.
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.
(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.
*** Bug 1011252 has been marked as a duplicate of this bug. ***
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.
*** Bug 1027624 has been marked as a duplicate of this bug. ***
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.
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.