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.
(U)EFI or (Unified) Extensible Firmware Interface is a specification for x86, x86-64, ARM, and Itanium platforms that defines a software interface between the operating system and the platform firmware/BIOS.
Is there any recourse? The way I see it, there are a few potential solutions:. Having an alternate bootloader for the Windows kernel. NOT a chainloader.
As far as I know, none exist. That's a shame. 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. 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.). 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? 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:. 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. Grab some UEFI DUET builds. Without question, the best place to get this is.
The actual build tarballs are under the master branch of the first repository,. Give it the old tar -xf. 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. 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. 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.). 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. Didn't test with Tianocore yet, though.
Anyway, thanks for everyone who tried to help. 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, 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.
![Uefi emulator Uefi emulator](https://a.fsdn.com/con/app/proj/cloverefiboot/screenshots/gui_start_shell_theme_mrengles.jpg/max/max/1)
You need to give up Windows boot manager. You do not have to install syslinux. Only the (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.
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 ddrescue 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 to Milind's thread.
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.
May be third party software helps. Does anybody used anything like this? The article 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. 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.
The EFI Development Kit (EDK) contains the public part of the original reference implementation developed by Intel. It includes source code, makefiles and binaries for the reference EFI Shell. Build tips (targets) include a Win32 (NT32) UEFI emulator and DUET (Developer’s UEFI Emulation) which create an emulated environment where you can test EFI applications and code without the need for an actual EFI-enabled Platform. One of the major problems with the EDK is that the build environment is very much Microsoft Windows centric. This reflects the heritage of the EDK. EFI was initially developed for the IA64 (Merced/Itanium) platform and the EDK, running on 32-bit Windows NT X86, was used by engineers in a number of companies to develop the firmware utilities and boot managers for their initial Itanium offerings.
I was one of those people who used the EDK back in the early 2000s. In order to build the EDK out of the box, you need specific versions of Microsoft Visual Studio (VS2003 or VS2005) and a specific version of the Microsoft Assembler (MASM 6.15). I have built both 32-bit and 64-bit versions of DUET using Visual Studio 2010 by modifying some of the build scripts but there is no easy replacement for MASM 6.15. If you do not already have a copy, or cannot obtain a copy, you cannot build the EDK. The assembler included with Visual Studio is not sufficient. Officially the EDK11 is the response to the community’s request for a better build and version tracking environment for UEFI and PI (Platform Initialization) development. From a developer’s perspective, the main difference between EDK and EDK11 is the enhanced build environment.
Gone are the dependencies on Visual Studio and MASM. In its place is a much more logical partitioning of the source code into what is termed.
Was released which contained a Unix package. I recently decided to see what it would take to build and run the UEFI emulator in the EDK11 on 64-bit Fedora 14. It turns out that it was surprisingly easy provided that you disabled the networking components in the Unix package. It looks like the Unix package was developed under Mac OS X or possibly o ne of the BSDs and then ported to Mac OS X as the networking components currently have a dependency on the Berkeley Packet Filter (BFP) in one critical file (.