Jump to content

how to load BCD menu in UEFI mode


richard

Recommended Posts

hi there,

as i know in legacy BIOS, pxelinux.0 would load bootmgr.exe and BCD, and then bootmgr.exe read BCD so that we can select different OS to install.

But how to do similar work in UEFI mode? i tried bootx64.efi, but it seems would not auto load bootmgr.efi and BCD as legacy BIOS, anybody could help? thanks in advance!

Link to comment
Share on other sites


i don't think so. i have set up a RHEL 6.1 server and config UEFI PXE boot, now my client machine could boot from a NIC which support UEFI PXE. My question is how to load windows set up menu like legacy BIOS to load BCD.

Link to comment
Share on other sites

Even Server 2008 R2 is capable of accepting a UEFI (Itanium EFI) PXE boot, but no hardware supports it. What hardware are you using that has a UEFI Boot Rom on it? I'd like to know because the lack of such hardware is holding back a couple of my projects.

Edited by Tripredacus
fixed error
Link to comment
Share on other sites

I have that NIC and we did that testing already. Yes it enables the UEFI boot but it still reports an arch of 6 (EFI IA32) which isn't the correct value to for a true UEFI PXE boot. For example, during this testing, I had built a boot image capable of installing Windows to a GPT Disc. This same boot image works as expected from a UEFI boot CD. But even with using both the flashed CT (we also did the GT card also) it still actually did a BIOS based PXE boot. The consequence was that the OS installed properly but a BIOS booted WinPE cannot write the boot-sector to a UEFI enabled disk. We had gone through Quad for this issue as well and Intel had told us they did not currently have any product available that was capable of the proper UEFI PXE boot for this purpose, and to expect it in the next wave (7 series) products.

However, during our testing, we ended up getting the "normal" BIOS type response from the PXE server. So our regular WDS boot menu worked as normal. I am not sure if we tried booting to the Linux server to see if it had worked or not.

I have a topic in the Hardware Hangout when i was working on that project you can check out.

Link to comment
Share on other sites

  • 2 months later...

VMware ESXi 5.0 offers EFI firmware support, including PXE. I've been looking at this just recently because I want to make sure all servers built from now on are legacy free. The EFI firmware correctly IDs itself from what I can see, because I can see from the WDS events that it does successfully TFTP download the file boot\x64\Bootmgfw.efi

However, it crashes and powers off the VM when it is executed, even though I'm on the latest ESXi (5.0U1). I followed the tips here:

http://support.microsoft.com/kb/2012858

I have been able to work around this for now using a WinPE ISO image with EFI support, while VMware support look into the issue for me. To do this I updated my unified Windows PE build script to support EFI. This single batch script will build x86 and/or x64 versions, will ingest drivers, supports wifi, builds ISOs, and will automatically freshen the WDS boot images when complete. It does not use any third party tools - only Microsoft's WAIK:

http://pcloadletter.co.uk/2011/12/03/windows-pe-builder-script-for-waik-including-wifi-support/

Edited by patters
Link to comment
Share on other sites

  • 3 months later...

I forgot all about my earlier post in this thread. I did get VMware EFI PXE booting with WDS working. Here's an update which may help someone.

VMware Support's testing made clear to me that the EFI PXE bootrom in vSphere 5.0 does definitely work, so I went back to my WDS server in more detail.

The Microsoft KB (http://support.microsoft.com/kb/2012858) which comes up while researching this issue is a bit misleading. It suggested that in case of problems, an EFI PXE client should be hard-configured in WDS/DHCP to boot the boot loader boot\x64\Bootmgfw.efi

In my infrastructure the WDS server is also a DHCP server. There are several workarounds for this since port 67 is used for both services. The first Microsoft-recommended method is to tick the boxes in the screenshot below:

post-16131-0-70771300-1343221098_thumb.p

The downside of this method is that if DHCP option 60 is configured, Windows puts this in for *all* DHCP scopes on the server. With DHCP option 60, DHCP option 67 (Boot File Name) is ignored. This is not ideal because you may need to have different PXE settings for different subnets, say if you had Linux clients, or wanted to use VMware Auto-Deploy for instance.

So, until now in my environment I had ticked the "Do not use port 67" option in that screenshot, but *not* the DHCP option 60. When this is the case, you need to define DHCP option 67 (Boot File Name). This had been set to boot\x86\wdsnbp.com so as to list all boot images on the WDS server as appropriate for both x86 and x64 clients. It worked fine like this for several years. When I was initially testing EFI PXE I consulted Microsoft KB2012858 and saw that I needed the loader boot\x64\bootmgfw.efi instead. But setting it to point to that file was crashing the VM.

It transpires that the *only* way to get EFI PXE working with WDS when that same server is also a DHCP server is in fact to use the DHCP option 60 in that screenshot. I haven't carried out a packet trace, but I can see from the WDS logs that it's a whole lot more complex than just handing the PXE client the bootmgfw.efi loader. What it seems actually happens is that a temporary BCD boot menu is built on the WDS server (the client downloaded \Tmp\x64{25986027-7DF6-4A64-8133-BCE5DCCF5542}.bcd) and the whole thing behaves just like Windows Vista/7/2008's own proper boot loader, with Boot.sdi, and the various fonts being downloaded individually too. Perhaps there's dynamically generated stuff being sent to the client. If it isn't done exactly in the prescribed way, it fails.

So really I think this ought to be made clearer in that Microsoft KB.

Edited by patters
Link to comment
Share on other sites

I was able to "kinda" get a physical PC to boot into EFI mode... but by forcing all default boot options to use that EFI rom, which results in client lockup. Here are the main problems... the EFI support in Server 2008 R2 (and earlier) is actually the Itanium-based EFI, not exactly the same as the current UEFI spec.

So Server 2008 R2 can detect clients with either:

-x86

-amd64

-ia64 (efi)

But, Server 2012 can detect these (note that Itanium support is removed)

-x86

-amd64

-x86x64

-arm

-uefi x86

-uefi x64

Note that any client that supports x64 PXE will be detected on Server 2012 as both x86 and x86x64 and may generate an error in Event Viewer.

I am not surprised that you can do an EFI PXE Boot using a VM, but then again it is using the legacy Itanium EFI profile.

Take a look at these I have posted after much (much) testing:

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...