Jump to content











Photo
* * * * * 1 votes

Hack Bootmgr to boot Windows in BIOS to GPT

bios gpt bootmgr winload

  • Please log in to reply
350 replies to this topic

#1 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 27 January 2014 - 09:32 PM

this forum is awesome, nowhere else have i found such detailed and insightful nitty-gritties about booting, windows in particular. so here is my idea

 

As you all know, windows supports only booting from a GPT disk in UEFI, but not in BIOS. But GPT is definitely a lot better, and cleaner. So can we do something about that?

 

The sequence of booting in Windows 7 (for now, later we can look at 8) : is 

 

MBR -> System volume (100MB) VBR ->bootmgr (with bcd) -> winload.exe -> ntoskrnl.exe -> others

 

We already have syslinux MBR which can setup a GPT reading MBR code... after which the VBR code need not be touched.... and then we come to bootmgr.

 

Is it not possible to modify bootmgr to be able to read GPT? Windows can certainly understand GPT, just that it hasn't shipped with a compatible bootloader. I checked winload.exe, and it does check for "EFI PART" GPT header signature, but dunno if it's positive or negative match it's checking for. winload might be difficult to patch, but maybe it won't mind it....?

 

I'm a noob at system programming, but have a fairly good idea about the process... But I defer to the experts here.... What say?


Edited by milindsmart, 27 January 2014 - 09:33 PM.


#2 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 29 January 2014 - 06:05 PM

Seriously.... No one is interested? On REBOOT.PRO!?



#3 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 29 January 2014 - 08:27 PM

OK I unpacked bootmgr.exe from the bootmgr on my system.... And examined it in IDA pro...

It's a very large application, and contains a lot of code... While searching for strings, I found FULL FLEDGED functions for reading the GPT entries, checking CRC, Finding which is the system partition, etc....

We also know bootmgfw.efi is the only REAL UEFI executable... Winload.efi certainly isn't... Neither was I able to load grub.efi.

So putting all this together, we can be fairly sure that it's not using too much of UEFI provided functionality, if we assume that those functions are meant to be used by bootmgfw.efi and is here only because Microsoft didn't want to fragment their codebase.

Also, syslinux which I mentioned, is not special in this regard, grub2 will also do the same.. So I tried windows on MBR vhd using hyper-v, then converted to gpt,
Then installed fedora. As expected it's unable to boot saying it can't find the BCD, but now I'm hoping to debug it...

I thought I'd be able to attach windbg, but since it never finds BCD, it can't see the bootdebug property set and allow debugging...

Any suggestions?

#4 joakim

joakim

    Silver Member

  • Team Reboot
  • 907 posts
  • Location:Bergen
  •  
    Norway

Posted 29 January 2014 - 08:38 PM

Sure, the challenge sounds interesting. But right now, time is my main constraint. Debugging this kind of stuff just takes longer than regular user mode stuff. It might not be an easy solution..



#5 cdob

cdob

    Gold Member

  • Expert
  • 1314 posts

Posted 29 January 2014 - 10:58 PM

it never finds BCD

Any suggestions?


Use a (virtual) floppy.
Copy bootmgr and \boot\bcd to the floppy. Adjust bcd, replace winload.efi to winload.exe.
Boot the floppy.

Given bcd is found: there is no need to patch bootmgr.
Bootmgr loads windows from a GPT hard disk at BIOS mode.
It works at a real virtual floppy inside a virtual machine.

Can you use syslinux to read a floppy image from GPT disk?

#6 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 30 January 2014 - 08:45 AM

I tried to put a floppy, but that didn't work... so using a 1GB hard disk... Unable to get it to boot....

 

It's saying "The boot selection failed because a required device was inaccessible"... code 0xc0000225. I traced that down to a function called _BmpCreateDevices... I can't see any disk IO style instructions here, so maybe BCD is not configured properly.

 

What I did was to set the "device partition=E:" in the bcdedit interface... Checking back in regedit, it shows a GUID... How do I check that it's the intended main hard disk? Maybe it's failing because the GUID there is not correct.



#7 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 30 January 2014 - 10:24 AM

Ok the GUIDs are correct, and they point to the correct disk... I verified it as explained here,

 

So I am positive that it is failing at _BmpCreateDevices() function.... which again doesn't do any actual disk I/O, so it must be done earlier... _BmpCreateDevices is called by _BmpLaunchBootEntry(), which ALSO doesn't do any disk I/O. If this call had succeeded, actually transferring control to winload.exe is relatively a very small amount of code from this point. _BmpLaunchBootEntry() is called by _BmMain() function which is the entry point of Bootmgr.exe. 

 

So I think what's happening here is that in an earlier step these devices are detected and this is stored somewhere, and doesn't throw an error, because, presumably, it's not an error as yet, or it doesn't know it yet. When _BmpCreateDevices() is called, it's reading this info, and throwing a fatal error.

 

On the other hand, @cdob, if you're saying that you have actually seen it work without any patching of bootmgr, then I'll continue to try...



#8 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 30 January 2014 - 11:16 AM

Ok I must have made a mistake there..... I created a new boot entry to the partition, and now I am getting 0xc000000e saying "The selected entry could not be loaded because the application is missing or corrupt"..

 

It's a small step... so BCD can see the partition, but can't boot the loader... hmm...



#9 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 30 January 2014 - 01:52 PM

BTW am able to debug, and as i suspected, it's BmpCreateDevices() and BmTransferControl() that are returning unacceptable values.

 

Can someone else also decompress and disassemble bootmgr.exe and check?



#10 cdob

cdob

    Gold Member

  • Expert
  • 1314 posts

Posted 30 January 2014 - 06:45 PM

you have actually seen it work without any patching of bootmgr


To clarify testing conditions:
I used a 12 GB IDE HDD at VMware Player.
And installed Windows 7 SP1 x64 at EFI mode.
Next added a floppy, applied "bcdedit /export a:\boot\bcd" and copy a:\bootmgr.
Adjusted bcd: bcdedit /store a:\boot\bcd

Windows Boot Manager
--------------------
identifier {bootmgr}
device boot
description Windows Boot Manager
inherit {globalsettings}
default {default}
resumeobject {08f8e6a3-a85b-11e2-b40f-d91efe663549}
displayorder {default}
toolsdisplayorder {memdiag}
timeout 30

Windows Boot Loader
-------------------
identifier {default}
device partition=C:
path \Windows\system32\winload.exe
description Windows 7
inherit {bootloadersettings}
recoverysequence {08f8e6a5-a85b-11e2-b40f-d91efe663549}
recoveryenabled Yes
osdevice partition=C:
systemroot \Windows
resumeobject {08f8e6a3-a85b-11e2-b40f-d91efe663549}
nx OptIn


Switched to BIOS mode and boot floppy a:
Windows 7 does boot, diskpart list a GPT hard disk.




added: New game:
Boot at BIOS mode and run

DISKPART:
sel disk 0
clean
convert gpt
create par primary size=100
format fs fat quick
assign letter=B
create par primary
format fs ntfs quick
assign letter=C

imagex /apply e:\sources\install.wim 3 c:\
bcdboot c:\windows /s b:

md a:\boot
attrib b:\bootmgr -s -h -r
copy b:\bootmgr a:\
copy b:\boot\bcd a:\boot\

Boot floppy, bootmgr loads bcd and winload.exe
Installation continous, devices are loaded.
Error: configuration not saved.

Game lost.

Edited by cdob, 30 January 2014 - 09:59 PM.


#11 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 31 January 2014 - 01:55 AM

Syslinux has gptmbr.bin which can be used to boot a GPT partition from BIOS. Then, if you have Syslinux on that partition, you can boot BootMgr. The problem is in the hand-over to BootMgr. The BIOS version of BootMgr uses a particular protocol for knowing where the system volume[1] is. The (U)EFI BootMgr uses a different protocol. What you're trying to do is to boot the BIOS BootMgr and say "Hey, I'm on MBR partition XXX." But there is no XXX, because you're on a GPT partition. The floppy case works because it's expected to be partitionless.

[1] http://support.microsoft.com/kb/314470

#12 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 31 January 2014 - 12:25 PM

@cdob : 

 

That's great, it means we can find a solution.... I will try out both your methods soon, but meanwhile, I would like to know... How are you making you floppy bootable? bootsect.exe?

 

The reason I ask is, as @Sha0 is saying, the handover to bootmgr is what causes a problem in case of an HDD without a floppy... I ran through the bootmgr.exe code many times, and verified that bootmgr.exe fails to read the partition because a particular value (@0x48e256) is not 0, (in my case, 1). BUT this code is NEVER written to in the course of execution of bootmgr.exe.... In Bochs I caught the write happening in 16 bit mode, before bootmgr.exe even starts execution.... and so I suspect the Volume boot record is messing things up for poor bootmgr.exe. 



#13 cdob

cdob

    Gold Member

  • Expert
  • 1314 posts

Posted 31 January 2014 - 04:55 PM

I will try out both your methods soon

The second approach failed. There is something missing.
 

How are you making you floppy bootable?

I did run format at Windows 7.

bootsect.exe?

Yes, this is another option.
 

bootmgr.exe fails to read the partition because a particular value (@0x48e256) is not 0, (in my case, 1).


This reminds to: Boot from USB/Firewire HD without BIOS support, Fake Signature Method
http://www.911cd.net...showtopic=21242
Ntldr stores a checksum of the MBR at 16 bit mode
Ntldr.exe does detect the boot drive that way.
Post #147 offers a program for cloning signature and checksum.

Does bootmgr do this still?
Does bootmgr uses MBR checksum at a GPT disk too?
Can we use this aproach sowmehow? syslinux memdisk a hard disk image.

But what's the benefit to a floppy image? I don't know.

joakim did: BOOTMGR with BCD embedded
http://reboot.pro/to...h-bcd-embedded/

Does particular value (@0x48e256) flags the floppy mode?
Can you patch bootmgr to enable floppy mode always?
Given bcd embedded and floppy mode always set:
a floppy is not required anymore.

#14 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 01 February 2014 - 07:06 AM

The second approach failed. There is something missing.

Ah... Hmm... So EFI to BIOS works..
 

I did run format at Windows 7.

Format? it does not have option to make a floppy bootable.
 

Yes, this is another option.

I will try as much as possible with what you did EXACTLY so that we can work from a common starting point
 

This reminds to: Boot from USB/Firewire HD without BIOS support, Fake Signature Method
http://www.911cd.net...showtopic=21242

Wow very interesting thread and work in this field! will be useful in the overall effort.
 

Ntldr stores a checksum of the MBR at 16 bit mode
Ntldr.exe does detect the boot drive that way.
Post #147 offers a program for cloning signature and checksum.

Does bootmgr do this still?
Does bootmgr uses MBR checksum at a GPT disk too?


Very interesting possibility, but I don't see how it can be... I have stepped through every function call, and there is no checksum of the MBR being calculated anywhere... It seems more like it's trying to call EFI firmware functions to read GPT and one of those set the byte to 01.

Besides, I also edited that memory back to 00.... In which case it takes the other branch, but eventually some other function writes the 01 to the memory... Will check which function when I get time...
 

Can we use this aproach sowmehow? syslinux memdisk a hard disk image.

But what's the benefit to a floppy image? I don't know.

Yeah, the sooner we get out of floppy land, the better... I mean we're trying to use more modern partitioning with BIOS.. If we can avoid regressing to floppies, that would be good.
 

joakim did: BOOTMGR with BCD embedded
http://reboot.pro/to...h-bcd-embedded/


I was JUST thinking of something like this! Awesome... This will remove the problem of bootmgr not finding bcd.. Eliminates a few issues. Of course, it may not be that hard to give it the facilities to find it the usual way
 

Does particular value (@0x48e256) flags the floppy mode?
Can you patch bootmgr to enable floppy mode always?
Given bcd embedded and floppy mode always set:
a floppy is not required anymore.


I doubt this is floppy mode either... it simply skips all the useful code when this bit is non-zero. I don't think this is floppy mode.. bcd embedded will be a good stepping stone..

BTW, VMWare player is giving me a strange CPU error on startup when I try using GPT disk with BIOS VM. Dunno what's up... but will test out with VirtualBox

Edited by milindsmart, 01 February 2014 - 07:07 AM.


#15 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 01 February 2014 - 07:48 AM

OMG HAHA IT WORKS! bootsect.exe on floppy..

@cdob I guess I didn't really believe you :P

so ... floppy + EFI-GPT installed Windows = boots in BIOS.
but ... MBR HDD + BIOS-MBR installed Windows = does not boot in BIOS

so next experiment... try MBR HDD + EFI-GPT installed Windows

this should be interesting... either the partition boot record is screwing things up... or there's some other magic going on.

Meanwhile, @cdob , @joakim and @Sha0, what are the *definitive* ways of finding out if Windows booted in UEFI or in BIOS mode? We can't rely on the MBR/GPT test anymore... And msinfo32.exe does not have the BIOS mode field in windows 7... setupact.log lists only the BIOS mode when it was set up...

@cdob, why is this not a tutorial at sevenforums and other Windows fora? Even experts such as Rod Smith and Jonathan de boyne Pollard claim that what we both have done is impossible...


Edited by milindsmart, 01 February 2014 - 08:33 AM.


#16 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 01 February 2014 - 09:02 AM

... It seems more like it's trying to call EFI firmware functions to read GPT and one of those set the byte to 01.
....
I doubt this is floppy mode either... it simply skips all the useful code when this bit is non-zero. I don't think this is floppy mode..


And of course this theory is junk, now that we have proof to the contrary. What I think is, the partition boot record (9 sectors of code) does some checking and sets it to flag the drive as a problem to bootmgr. In which case, chainloading bootmgr directly instead of the system partition VBR might work.

#17 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 01 February 2014 - 01:21 PM

IT WORKS!!

MBR HDD + EFI-GPT installed Windows = BOOTS in BIOS!

To recap :
1) Install Windows 7 in UEFI enabled VM on GPT hard disk
2) add new small (I used 1GB) MBR hard disk
3) create NTFS partition and mark active
4) use bcdboot to get all files on it
5) use bootsect /nt60 /mbr /force to write both bootsectors (MBR and VBR) at once.
6) bcdedit /store [the new bcd] and change {bootmgr} device to "boot"
7) boot using small MBR HDD
8) profit

So there was something I did wrong with the previous time I used an MBR hard disk to hold BCD.. Which I now suspect was (1) using a FAT32 partition.... either that, or (2) installing using EFI does some magic that converting MBR to GPT doesn't do. I suspect (1) a lot more than (2)

I can't believe this would be this simple... with all the experts stating dogmatically that Windows on GPT through BIOS won't boot, unless using 1) Hybrid MBR or 2) UEFI DUET... Which is frankly excessive considering bootmgr is actually tremendously capable... Using @Joakim's bootmgr with embedded bcd, we can solve it immediately I suppose.. Will try it asap.

Edited by milindsmart, 01 February 2014 - 01:43 PM.


#18 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 01 February 2014 - 07:29 PM

MBR HDD + BIOS-MBR installed Windows then converted to GPT = WORKS!

So booting from BIOS *NEEDS* an NTFS system partition...

Next is to try with Grub, directly chainload bootmgr, not running the partition boot record..

Another idea... you can put an *entire* _MBR partitioned disk_ in a *single* _GPT partition_, it's a fully supported thing... There's a specific GUID for such a MBR-holding partition.

So if windows NEEDS an MBR to boot, can we use a tiny MBR disk in its own GPT partition?

#19 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 01 February 2014 - 08:42 PM

Take a look here[1]. Read the bit about what the SI register contains, for the hand-over protocol. That means that the BIOS version of BootMgr expects that if it's booted from an HDD, this protocol is followed and it should look for the system volume (the filesystem with the BCD) on a particular MBR partition. The protocol doesn't have a way to say "you're booting a GPT partition."

Having said that, I mentioned that Syslinux has gptmbr.bin and it follows a protocol which tries to "trick" the booted program into thinking that the MBR protocol has been followed. Whether or not the booted program is tricked is another matter. Have you tried gptmbr.bin? If not, please do.

Once Windows has been booted, there exist (U)EFI runtime services if the system was booted in (U)EFI mode. These will not be available if the system used BIOS. This should help you to distinguish between the two scenarios.
 
[1] http://www.ata-atapi.../hiwmbr.html#T3

#20 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 01 February 2014 - 10:03 PM

@Sha0 : this shows that it's never used in practice..

The problem is that I have to assemble gptmbr.bin, and having never worked with an assembler before, I am not sure what the various parameters in the gptmbr.s file that I have in my copy of syslinux are. Where would I get the direct binary file?

But yes, we will have to assemble that class of MBRs soon anyway...

You see, I just tried installing fedora and grub on that MBR -> GPT converted disk... and now it's STOPPED booting, even from the MBR HDD that used to work flawlessly. @cdob That's why my previous attempt didn't work... I had installed grub.

So Grub is messing up further efforts. Mostly, we'll have to use gptmbr.bin, or this.

Testing for UEFI services is THE answer... Thanks!

Edited by milindsmart, 01 February 2014 - 10:28 PM.


#21 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 02 February 2014 - 01:38 AM

@Sha0 : this shows that it's never used in practice..

If neither the VBR code nor BootMgr care about the DS:SI, then that's even better! You shouldn't need to hack anything, unless the BIOS version of BootMgr tries to determine the system volume by examining the MBR.
 

Where would I get the direct binary file?

You can get the Syslinux 4.07 .ZIP file from here[1].  Inside, there is an mbr/ directory with gptmbr.bin.

Here[2] is the description of the hand-over protocol that gptmbr.bin uses.

[1] http://www.syslinux....ex.php/Download
[2] http://git.zytor.com...1b4;hb=HEAD#l40

#22 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 02 February 2014 - 04:46 AM

@cdob : I think you're right once again, about the checksum. I think it's the partition VBR which calculates the checksum... or maybe the 16-bit mode stub of bootmgr...

I was only saying it's not bootmgr, and I hadn't thought of other checksum-calculating components, silly me.

Luckily the tools all exist here.

The bigger thing is, can we add a new section of binary code that enables bootmgr to find BCD on a GPT disk, and disable the signature check in the proces? If the checksum turned out to be the only problem, that is..

#23 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 02 February 2014 - 03:39 PM

Grub had changed the MBR disk signature of the GPT disk (I don't know if it's even legal to have a disk signature in the MBR on a GPT disk)....

 

I restored the old signature, but still bootmgr refuses to boot. So either

  1. it verifies a checksum, in which case gptmbr.bin won't make a difference,
  2. some other grub damage that we don't know about

So the next experiment : Luckily this was the EFI-GPT installed windows, hence it has a EFI System Partition... I'll boot in EFI mode in VMWare Player and repair it so that it functions as before. Then I'll repeat the above steps, take a backup of the MBR, and change a single byte to see if that causes a problem. If yes, it's 1) . If not, it's some other damage of grub, 2)

 

On another note, it seems that even finding BCD on the erstwhile MBR system partition in the GPT drive is not an issue for bootmgr, as I had thought earlier... It gives the exact same error either booting from the 1GB MBR HDD, or from the Grub entry. This issue seems to be the last bottleneck to get a completely-non-hackish approach to boot Windows on BIOS from GPT.



#24 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 02 February 2014 - 08:39 PM

Well, writing a proper compliant MS protective MBR is not so easy when it's GPT! :) The install dvd utilities barf on GPT for bootsector purposes.

 

I fixed the problem (with pure fiddling) by writing a New Protective MBR using Rod Smith's gdisk tool (expert functionality). BUT the Grub code that existed still WORKS! So it's (2) some repairable Grub damage, Grub itself is not the issue .... another thing to keep in mind.

 

I'll diff the MBRs tomorrow. Meanwhile, bootmgr still has problems with finding BCD file on a GPT disk, above post was a false hope, it was booting to the MBR hdd boot menu. 

 

There's something very very weird going on in the protective MBR, VBR, and bootmgr... 



#25 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 03 February 2014 - 07:20 AM

There's something very very weird going on in the protective MBR, VBR, and bootmgr...

It's kind of like you're avoiding the suggestion of trying gptmbr.bin, whose documentation explains[1] that Microsoft operating systems can be booted on GPT disks with BIOS firmware using a hybrid MBR.

Below are some [Linux] steps that you can use to produce your very own GPT disk with a hybrid MBR that will boot BootMgr. In the steps, replace E9FF9048-9B1B-4E4A-9646-8B325654B3DD with the GUID of the partition, as shown by gdisk.

I've also attached an example disk image. Simply copy in BootMgr and put a BCD into the Boot/ directory, then use the disk image with QEmu with 16 heads (which might be the default).
dd if=/dev/zero of=gptbootmgr.hdd seek=197568 count=0
gdisk gptbootmgr.hdd
n (new partition)
1 (partition number)
129024 (first sector)
196559 (last sector)
0700 (partition type)
i 1 (examine partition)
x (expert mode)
a (change attributes)
2 (legacy BIOS bootable)
<enter> (finished)
r (recovery mode)
h (make hybrid)
1 (first partition)
y (first protective partition)
ef (efi system partition type)
y (bootable flag)
y (second protective partition)
ee (protective partition type)
w
y
losetup -o 66060288 --sizelimit 34707456 /dev/loop0 gptbootmgr.hdd
dd if=/path/to/syslinux/mbr/gptmbr.bin of=gptbootmgr.hdd bs=1 count=440 conv=notrunc
mkfs.vfat -n BootMgr -F 32 /dev/loop0
mkdir mymount
mount /dev/loop0 mymount
/path/to/syslinux/extlinux/extlinux -i -H 16 mymount
cp /path/to/syslinux/com32/chain/chain.c32 mymount
echo DEFAULT bootmgr > mymount/syslinux.cfg
echo LABEL bootmgr >> mymount/syslinux.cfg
echo COM32 chain.c32 >> mymount/syslinux.cfg
echo APPEND guid:E9FF9048-9B1B-4E4A-9646-8B325654B3DD ntldr=/bootmgr >> mymount/syslinux.cfg
cp bootmgr mymount
mkdir mymount/Boot
cp bcd mymount/Boot/BCD
umount mymount
losetup -d /dev/loop0
qemu -hda gptbootmgr.hdd
Enjoy!

[1] http://git.zytor.com...1b4;hb=HEAD#l23

Attached Files







Also tagged with one or more of these keywords: bios, gpt, bootmgr, winload

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users