I'd like to know if there's a method to get Windows 7 or Windows 8 Developer Preview to install to a GPT disk on my traditional IBM PC BIOS setup. Windows 7, of course, rejects my GPT partition, because I don't have UEFI. Well, Debian and Grub 2 seem to work fine... So I want to know if there's a way to force Windows to work as well.

I'd seriously prefer avoiding hybrid MBR/GPT, because it's quite fragile and feels hackish, but it does work. I would assume the main blocker is that Microsoft is simply not adding support in their BIOS bootloader for GPT, which is understandable, I suppose. Is there any recourse?

The way I see it, there are a few potential solutions:

  1. Having an alternate bootloader for the Windows kernel. NOT a chainloader. As far as I know, none exist. That's a shame.
  2. Storing as little as possible on an alternate MBR-based disk. Not liking this idea, but it's doable. I'm not sure I'd call this a solution to the problem as much as a workaround.
  3. Emulating EFI enough to get the EFI bootloader to work... I remember hearing a bit about a UEFI-on-BIOS emulator, but I can't find anything about it now. I assume this is doable, but there's probably not much demand for it yet, and it's probably no fun at all to setup. GRUB 2 seems to be able to boot a hackintosh with necessary EFI emulation, but I guess there's no interest/UEFI 2 is harder to approach (and I would assume other EFI emulators used for hackintosh are on the same boat.)
  4. Coreboot with TainoCore. Coreboot does not work on my motherboard (as far as I know,) and I'm quite sure the last effort to do this during GSoC was a failure. I'd absolutely love this solution, if it did work, though.

Am I missing anything?

  • 1
    Not quite. I know it can run on hybrid MBR/GPT and I'm not afraid to use it. More, I'm dissatisfied with that solution and want to know if there is another, better way. I'm still working on this issue, though, and I might find my own solution. Commented Oct 22, 2011 at 7:40
  • 1
    I'm pretty sure That question is a duplicate of this one, given the 2 year disparity. Besides that, there is really no answer to the question there, or at least not a direct one, whereas this question has a direct answer. Commented Feb 4, 2014 at 2:49
  • Did you check my answer? It's new, and no one else has done it this way. Would like some testing on it. Guaranteed non hacky.
    – Milind R
    Commented Feb 8, 2014 at 22:06
  • It really won't work on a laptop, though. But again, I find it awfully strange to flag this question as a duplicate after it was sufficiently answered nearly 2 years before that question was even asked. I do not find running a UEFI implementation to be hackish; just outlandish, but it has the advantage of not requiring additional disk drives. Commented Feb 9, 2014 at 10:47
  • There is a single disk implementation in the works, will update when it's tested... Also, it's a hack in the sense that you're lying to windows about the system : in hybrid MBR, lying about the partition type, in DUET, lying about the firmware.
    – Milind R
    Commented Feb 11, 2014 at 6:25

7 Answers 7


Well, things have changed since I first asked this question. For one, my PC is now UEFI based, so I don't have this problem anymore. Well, sort of. I had interest on pulling a similar setup on my laptop (GPT partitions, etc.) I finally managed to get a working Tianocore UEFI DUET setup, and it was about as painfully simple as it gets!

This assumes you want all shiny, new setups. If you want to actually convert your old setup, good luck. Actually, good luck either way, as this is a spotty operation in any situation.

A word of warning: If you're a fan of quick boot times, you may want to rethink this decision. Not that UEFI DUET is slow, but it adds another stage to your boot process, so if your BIOS/POST isn't fast, you may not like this.

Without further ado:

  1. You'll want a Linux setup. I used Fedora 16 off of a USB stick (with UNetBootin) and I'd highly recommend that because it practically works out of the box. You need a USB drive anyway, so don't plan on continuing without one.

  2. Grab some UEFI DUET builds. Without question, the best place to get this is here. The actual build tarballs are under the master branch of the first repository, here. Give it the old tar -xf.

  3. Setup your partitions. You should reserve 200 MB somewhere on the disk (very much preferably the beginning, and first partition.) You can format it with FAT32, but we're reformatting it later. Just make sure it shows up as a partition. You should use GPT here.

  4. Now install any additional software you may need. On the Fedora Live distribution, I found I needed yum install gdisk. I think that was it.

  5. Now go into the extracted builds directory. chmod +x ./duet-install and ./duet-install -64 -F -m /dev/sda1 (where /dev/sda1 is your desired EFI system partition.)

  6. Cross your fingers and reboot. With any luck, you'll see the TianoCore logo in just a few moments. If so, you are probably good! You'll need to setup your OS installation files on a USB drive - Tianocore does not support CD-ROM/DVD-ROM drives out of the box (and I don't know of any drivers for it.)

You may also desire some UEFI shell binaries to play with. I found some here. Didn't test with Tianocore yet, though.

Anyway, thanks for everyone who tried to help.

  • This works with Windows installations?
    – Moab
    Commented Aug 18, 2016 at 23:09
  • I was using it successfully with Windows 8 back in 2012. I don't need it anymore because everything made in the past few years uses UEFI, because Windows 8+ requires hardware manufacturers to support it. It probably would still work today, but I don't know if I would recommend it. Commented Aug 28, 2016 at 16:32
  • 2
    The UEFI DUET link should now be here, but it is no longer maintained; the site says to use Clover EFI instead. Commented May 30, 2017 at 18:26
  • 1
    and you can install Clover to HDD to remove the need of a separate drive
    – phuclv
    Commented Jul 10, 2018 at 2:54

I managed to boot Windows 8.1 on a GPT disk under a BIOS setup WITHOUT a second MBR disk.

The story was: My laptop was under a BIOS + GPT setup, with only Arch Linux installed. Recently I need to accomplish some tasks in Windows (which virtual machines cannot) so I am struggling to install Windows under my existing BIOS + GPT setup. According to Milind's answer, I managed to install Windows boot files (Boot, bootmgr, etc) to a (small) MBR USB drive. And each time I power on my laptop with that USB drive plugged in, I can boot into Windows 8.1, after which the drive can be plugged out safely.

The drawback is obvious: I need to carry a USB drive with me to boot Windows. So I was always trying to get rid of it.

After trying with different methods, I finally found the memdisk module of syslinux project worked.

  • You need to give up Windows boot manager.
  • You do not have to install syslinux. Only the memdisk module (a 26 kB file) is needed.
  • You can use many bootloaders to load this module, in my case, my favourite bootloader GRUB (version 2).

Here is the outline of how-to:

  • Partition your GPT disk to meet GRUB's needs, that is to say, a small partition to embed core.img. Detailed link
  • Install GRUB to that small partition.
  • Install Windows with imagex. And use bootsect and bcdboot to install Windows boot files into a small MBR USB disk..
  • Use dd or dd_rescue to clone your small USB disk into a disk image. (Your USB disk has finished its job.) The image may be too big for memdisk to load, you can mount it and shrink the filesystem / partition in it.
  • According to my test, you do not need a physical MBR disk to install Windows boot files into. You can create a vhd file and treat it as a physical disk. After installing Windows boot files into the vhd, you can convert it to raw (dd style) disk image using tools provided by VirtualBox or QEUM. When created with type=fixed, the vhd file is just a normal raw disk image (dd-style) with 512 Bytes footer. The footer will be recognized as "unpartitioned space" and will be ignored, so a type=fixed vhd file can be directly fed to MEMDISK without converting and thus boot the Windows.
  • Configure GRUB to use memdisk to load this disk image.
  • Windows will boot.

A detailed how-to can be found in my reboot.pro reply to Milind's thread.

  • 1
    @wzboy I'm using Arch linux and I managed to get after the point of installing windows (with wimlib-imagex). Now I'm not sure how to continue. Would you be able to elaborate on how to create the vhd file from within a linux distribution? Commented Jul 31, 2014 at 16:42
  • @MihaiBişog You need a Windows PE to create that vhd. There many ways to boot into Windows PE. GRUB and syslinux can boot into iso files, for example. Commented Aug 3, 2014 at 7:50
  • Isn't this will break windows updates? I mean, if Microsoft will release update which should modify these boot/bootmgr files which you put into virtual disk image - they won't be updated and you even never notice this. Also I suppose this may break some windows repair operations. Is there are any other downsides?
    – Powerman
    Commented Sep 12, 2014 at 10:36
  • In fact, BCD/Bootmgr will never be found by Windows, since it resides inside a floppy/disk image. So no question of auto-updating it. Auto-repair will not work. Anything related to microsoft tools related to your bootup will likely not work.
    – Milind R
    Commented Sep 12, 2014 at 11:57
  • 1
    Yes, anything related to bootmgr will not work, since they are "gone" after helping your Windows to boot. In fact, when you run "bcdedit" in cmd.exe it will tell you that it cannot find boot files. :-) Commented Sep 12, 2014 at 14:19

If you even have a small spare drive, you can boot Windows(either 32 or 64 bit) from GPT on BIOS. A floppy will do.

Boot into the Windows install/repair disc.

Create the system drive on the small disk/floppy, and use bcdboot to put your boot files on the the newly created drive on the small disk. Add a bootsector with bootsect. Change the {bootmgr} device to boot. Boot from small disk.

Steps are detailed here.

  • 2
    Tried that and it worked. Now I have a working Windows 8.1 on a GPT disk under a BIOS setup. All I have to do is to insert my USB flash drive to boot it. After booting process the USB drive can be removed. Just like the old times, I mean MS-DOS floppy... Commented Apr 5, 2014 at 5:18
  • Lol. I'm working on a solution that doesn't require another disk. Can you tell me how slow/fast it is?
    – Milind R
    Commented Apr 5, 2014 at 5:20
  • 1
    I think putting bootmgr on another disk does not make booting Windows longer, at least I does not feel it. Commented Apr 5, 2014 at 9:04
  • 2
    OHHHH YES. Apologies for being too excited. I spent a whole afternoon and finally managed to boot Windows 8.1 on a GPT disk under a BIOS setupt WITHOUT a second (small) MBR disk - by using syslinux memdisk module which is capable of loading harddisk image. Commented May 25, 2014 at 6:49
  • 1
    Here is my post: reboot.pro/topic/… Commented May 26, 2014 at 5:18

Big thanks to wzyboy.

I faced with this problem when tried to install Windows 2012 to Dell PowerEdge 2950 with 6Tb RAID. It hasn't UEFI.

I carried out some experiments. First I created 32Mb virtual HDD, as wzyboy said, and simply copied all stuff from Microsoft reserved partition. Windows was started normally. But with this solution, Hyper-V service unable to start.

As memdisk wiki says, it automatically decide by image size, what of kind media it have to emulate. So, I created virtual 720K floppy in WMware environment, and copied bootmgr, BCD and bootstat.dat in it(just in case, deleted memtest submenu from BCD store). Floppy size I choozed as small as possible, so it may be bigger or even smaller, I don't tried.

Now it boots from GPT drive and Hyper-V works good.

P.S. may be third party software helps. Does anybody used anything like this? https://www.terabyteunlimited.com/bootit-bare-metal.htm

  • Lately, after I spent many hours on image tricks, I found RAID-controller Perc5-i capable to slice array smaller then physical hard drive capacity. So, on professional hardware GPT booting isn't issue. Commented Jun 18, 2014 at 10:15
  • Can you please narrate your scenario and your fix for it, in this dev thread? I'm trying to keep all the details together.
    – Milind R
    Commented Aug 1, 2014 at 18:47

The article A BIOS to UEFI Transformation describes in detail how to use TainoCore UEFI DUET.

I understand that you have had problems using TainoCore, but perhaps this article will work for you.

The article does say :

Some computers don't work with UEFI DUET. Most importantly, it's really only useful on 64-bit x86-64 computers, especially in binary form. In fact, it doesn't start up properly even on some x86-64 computers. In tests on five x86-64 systems, I managed to get one or both versions working on just three computers—a pretty dismal success rate, really. It may just be coincidence, but the two computers that worked best for me used Intel CPUs, whereas the two that worked worst and the one that worked with version 2.1 but not version 2.3 all had AMD CPUs.

This seems to imply that one should try several versions of UEFI DUET before giving up.

It would help to know the model of your computer.

  • Since I last updated this question, I actually did get UEFI DUET to successfully boot on my computer. Sadly, the lack of a DVD-ROM driver killed me, as I didn't have any USB drives to store Windows on. After my primary harddrive randomly failed, I decided to give it a rest and use BIOS partitioning on a spare. However, this article is definitely helpful, and I'm still interested in getting this to work on my own. I'll try to remember to pick up a flash drive some time soon. Commented Dec 9, 2011 at 0:00
  • @JohnChadwick you can use Clover and install it to HDD so that you don't need a separate boot drive anymore
    – phuclv
    Commented Jul 10, 2018 at 2:47
  • @phuclv: Did you notice that the comment by John Chadwick is from 2011 and that he has given his own answer to this post?
    – harrymc
    Commented Jul 10, 2018 at 6:16
  • @harrymc of course I know. That info is for future readers
    – phuclv
    Commented Jul 15, 2018 at 4:31

Pretty much the only obstacle to booting Windows 7 (and later) on a BIOS/GPT system is that BOOTMGR is unable to locate the Boot Configuration Data file (BCD) when it’s located on a GPT partition. Once BCD is read, the OS partition is easily located and the booted system manages to access GPT disks just fine. In fact, the deeper you dig, the sillier it gets: the core part of BOOTMGR (which shows the menu and actually loads the NT kernel and basic drivers into memory) understands GPT partitioning perfectly, but the loader part which loads and incubates the former can only communicate being booted from an MBR partition. So the boot manager would inevitably be looking for an MBR partition on a GPT-partitioned disk.

In short, BOOTMGR can read GPT partitions just fine, even on a BIOS system: it’s just that it has no capacity to be told it’s just been booted from one.

One way around this, if you happen to have a bootloader capable of loading Linux kernels, is to use wimboot from the iPXE project. Although it is advertised as a tool to perform network boot of .wim files, it is in fact just a shim around BOOTMGR that supplies the latter with a virtual FAT file system from which it can access the BCD store; it’s perfectly usable locally, without network boot. To accomplish its task, wimboot must be supplied with a newc-format (non-checksummed SVR4) cpio image containing at the very least BOOTMGR and the BCD. The following instructions assume GRUB2; adapt them to your bootloader as necessary.

  1. Obtain the latest release of wimboot.

  2. Prepare both Windows RE and Linux (e.g. SystemRescue) boot media.

  3. Boot into Linux to convert the partition table: use gdisk or other tool to convert your MBR partition table to pure GPT. (DO NOT use a hybrid MBR; any MBR partition entries other than the GPT protective entry will lead Windows to consider your disk an MBR-partitioned one.) Ensure you have a BIOS Boot Partition and install GRUB2 into it. Copy wimboot to a GRUB-accessible location.

  4. Boot into Windows RE to prepare the BCD store: use bcdedit to ensure all device properties (entry properties device, osdevice, filedevice, ramdisksdidevice, and probably others) point to your actual concrete disk volume, e.g. partition=C: or ramdisk=[C:]\.... If a given entry’s properties have the value boot or even worse, unknown, correct them as follows:

    bcdedit /store c:\boot\bcd /set {default} device partition=c:
    bcdedit /store c:\boot\bcd /set {default} osdevice partition=c:

    Preferably do this not only for the main boot entry ({default}), but also for diagnostic-tool and hibernation entries as necessary; use bcdedit /store c:\boot\bcd /enum all to see them. If your BCD store contains entries referring to files from multiple partitions, you will have to manually ensure that each entry points to the correct one.

    The reason you need to do this is that wimboot treats the virtual FAT file system it serves to BOOTMGR as the boot device. Therefore any references to “the boot device” from within the BCD will now refer to the virtual file system, and not to the partition where Windows is actually installed. Furthermore, if any entry had previously referred to an MBR partition on the disk, then by converting the disk, you have invalidated that reference and you have to update it to refer to the GPT partition for it to keep working.

    You will have to repeat this step each time the Windows OS partition changes its UUID stored in the GPT; ideally, this should only happen when repartitioning the disk from scratch, but for safety, you can perform it after any kind of repartitioning.

  5. Add a wimboot menu entry to GRUB. The following uses GRUB’s built-in cpio support to construct an archive on the fly. For other bootloaders, you may need to manually construct a separate cpio archive (remember to use the -Hnewc option) and ensure it contains the fresh BCD, and regenerate it each time you update BOOTMGR and/or the BCD.

    menuentry "Windows 7" {
        set color_normal=white/black
        terminal_output console
        linux16 /boot/wimboot rawbcd
        search --fs-uuid --set=root [volume ID]
        initrd16 \
            newc:bootmgr:/bootmgr \

    Adjust letter case as necessary to match the file system.

  6. You are done: reboot into your bootloader. Compared to normal MBR boot, you may experience some cosmetic degradation (the splash animation may be different, BOOTMGR may display everything in English and/or fail to display menus in graphical mode), but other than that, Windows should be able to start normally. Those issues can be remedied by tweaking the cpio image to include fonts (/Boot/Fonts) and .mui translation files (/Boot/??-??/*.mui), and by passing the gui kernel command line parameter to wimboot.


People need to keep in mind that not all bios firmware are able to deal with a GPT drive. I have a USB Seagate 4 Tb drive that was GPT from the factory and neither of my two computers would boot with the drive plugged into the USB port.

The machines will freeze at the F2 Enter Setup F10 Boot menu screen and the only thing that can be done at that point is to turn the power off and turn it back on.

Once I converted the drive to MBR which kills about 2 Tb of drive space, both systems will start and boot into the OS as normal with the drive connected.

I'm looking for a BIOS patch to rectify this problem.

  • 1
    BIOS doesn't know anything about the drive, whether GPT or MBR, or even BSD label or APM... It just loads the first sector (i.e. MBR) and run it. At that point the job of the BIOS can be considered "finished". If your drive doesn't boot, it just means that there's no valid boot sector on the drive
    – phuclv
    Commented Jul 10, 2018 at 2:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .