Jump to content











Photo
- - - - -

Chainload WinPE - PXE UEFI


  • Please log in to reply
43 replies to this topic

#1 Leandro Paulin

Leandro Paulin

    Newbie

  • Members
  • 22 posts
  •  
    Brazil

Posted 19 December 2013 - 06:54 PM

Hello,
 
I’d like to know how can I chainload WinPE using GRUB2 in UEFI mode.
Let me explain better…
 
We have a PXE environment for BIOS Legacy and UEFI computers. The same server (WDS Windows 2012) is used for both Legacy and UEFI.
 
To boot different OS’s (WinPE, Linux, DOS) in Legacy Mode we’re using PXELinux. There is also a PXELinux Menu to the user choose which OS he wants. To boot WinPE in Legacy mode we use:

MENU LABEL WinPE
  KERNEL Boot/pxeboot.0
  APPEND –
 

Our Legacy PXE environment is working just fine.
 
For UEFI computers, we only use WinPE, so once the computer boots the WDS’s server sends WinPE (x64) without showing a menu to the user. However, now we want to start using Clonezilla in UEFI, therefore after the computer boots we need to show a menu to the user to choose (WinPE or Clonezilla).
I could make the menu work in UEFI with GRUB2. So after the UEFI PXE boot, it’s shown a menu and the user can boot Clonezilla. This is working OK.
 
To chainload WinPE in GRUB2 I’m using:

menuentry "WinPE" {
   insmod chain
   chainloader /Boot/x64/bootmgfw.efi
} 

 
WinPE starts to boot but fail with error code 0xc0000428 (The digital signature for this file couldn’t be verified).
 
Does anymore know how to chainload WinPE correctly in UEFI?
 
Thanks,
Leandro Paulin



#2 llbranco

llbranco

    Member

  • Members
  • 43 posts
  •  
    Brazil

Posted 20 December 2013 - 06:42 PM

following
seguindo



#3 Sha0

Sha0

    WinVBlock Dev

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

Posted 21 December 2013 - 11:50 PM

Capture the network traffic for the (U)EFI scenario with WDS. Find out which files WDS is sending to the (U)EFI computer. Find out which special PXE options WDS has sent, if any. You can use Wireshark to start capturing network traffic on the WDS system, then power on the client computer to a successful WDS scenario, then as soon as the client computer appears to have booted Microsoft Windows, you can stop the capture and review it.

I would guess that BootMgFw doesn't know that it's supposed to use the network and so it's not requesting the next file in the boot process. (Which I believe is BootMgr, but I could be mistaken.)

#4 Leandro Paulin

Leandro Paulin

    Newbie

  • Members
  • 22 posts
  •  
    Brazil

Posted 27 December 2013 - 02:19 PM

I have captured the network traffic with wireshark.
 
1) WinPE Legacy boot with PXELinux
   This is the WinPE PXE boot for Legacy BIOS computers. The WDS's default boot program (x86 and x64) were changed to "pxelinux.0".

1.1) DHCP negotiation
      - Next server: 192.168.1.10 (WDS Server)
      - Boot file name: "" (empty)
      - Option 67 (Bootfile Name): "" (empty)
1.2) DHCP negotiation
      - Next server: 192.168.1.10 (WDS Server)
      - Boot file name: boot\x86\wdsnbp.com
      - BCD File: \tmp\x86{...}.bcd
1.3) Read request: boot\x86\wdsnbp.com
1.4) DHCP Request
1.5) DHCP ACK
      - Next server: 192.168.1.10
      - Boot file name: pxelinux.0
      - BCD File: \tmp\x86{...}.bcd
1.6) Read request: pxelinux.0
1.7) Read request: pxelinux.cfg\default
1.8) Read request: pxelinux.cfg\Menu\default.menu
1.9) Read request: pxelinux.cfg\Menu\menu.c32
1.10) Read request: pxelinux.cfg\default
1.11) Read request: pxelinux.cfg\Menu\default.menu
1.12) Read request: Boot/pxeboot.0
1.13) Read request: bootmgr.exe
1.14) Read request: \Tmp\x86x64{...}.bcd
1.15) Read request: \hiberfil.sys
      - Error: file not found
1.16) Read request: \Boot\x64\Images\winpe_amd64_20131030.wim
      - Error: TFTP aborted
1.17) Read request: \Boot\Boot.sdi
      - Error: TFTP aborted
1.18) Read request: \boot\fonts\wgl4_boot.ttf
1.19) Read request: \Boot\x64\Images\winpe_amd64_20131030.wim
      - WinPE boot successfully

 
2) WinPE UEFI WDS
   This is the default WinPE UEFI boot in WDS (WDS configuration wasn't changed).

2.1) DHCP negotiation
      - Next server: 192.168.1.10 (WDS Server)
      - Boot file name: "" (empty)
      - Option 66 (TFTP Server Name): 192.168.1.10 (WDS Server)
      - Option 67 (Bootfile Name): "" (empty)
2.2) altserviceboot (4011) Request
2.3) altserviceboot (4011) Response
      - Boot file: boot\x64\wdsmgfw.efi
      - BCD File: \tmp\x64uefi{...}.bcd
2.4) Read request: boot\x64\wdsmgfw.efi
2.5) DHCP Request
2.6) DHCP ACK
      - Next server: 192.168.1.10 (WDS Server)
      - Boot file name: Boot\x64\bootmgfw.efi
      - BCD File: \tmp\x64uefi{...}.bcd
2.7) Read request: boot\x64\bootmgfw.efi
2.8) Read Request: \Boot\x64\BCD
      -  Error: file not found
2.9) Read Request: \Tmp\x64uefi{9474C15E-088A-447F-90D9-2236AACE1048}.bcd
2.10) Read request: \Boot\x64\bootmgfw.efi
2.11) Read request: \Boot\x64\Images\winpe_amd64_20131030.wim
      - Error: TFTP aborted
2.12) Read request: \Boot\Boot.sdi
      - Error: TFTP aborted
2.13) Read request: \Boot\fonts\wgl4_boot.ttf
2.14) Read request: \Boot\Boot.sdi
2.15) Read request: \Boot\x64\Images\winpe_amd64_20131030.wim
      - WinPE boot successfully    

 
3) WinPE boot without GRUB 
   The default boot program for "x64uefi" architecture in WDS was changed to "Boot\x64\bootmgfw.efi".

3.1) DHCP negotiation
      - Next server: 192.168.1.10 (WDS Server)
      - Boot file name: "" (empty)
      - Option 66 (TFTP Server Name): 192.168.1.10 (WDS Server)
      - Option 67 (Bootfile Name): "" (empty)
3.2) altserviceboot (4011) Request
3.3) altserviceboot (4011) Response
      - Boot file: boot\x64\bootmgfw.efi
      - BCD File: \tmp\x64uefi{...}.bcd
3.4) Read request: boot\x64\bootmgfw.efi
3.5) Read Request: \Boot\x64\BCD
      - Error: file not found
3.6) Read Request: \Tmp\x64uefi{9474C15E-088A-447F-90D9-2236AACE1048}.bcd
3.7) Read request: \Boot\x64\bootmgfw.efi
3.8) Read request: \Boot\x64\Images\winpe_amd64_20131030.wim
      - Error: TFTP aborted
3.9) Read request: \Boot\Boot.sdi
      - Error: TFTP aborted
3.10) Read request: \Boot\fonts\wgl4_boot.ttf
3.11) Read request: \Boot\Boot.sdi
3.12) Read request: \Boot\x64\Images\winpe_amd64_20131030.wim
      - WinPE boot successfully 

 
4) WinPE boot with GRUB
   The default boot program for "x64uefi" architecture in WDS was changed to "grub\bootx64.efi".

4.1) DHCP negotiation
      - Next server: 192.168.1.10 (WDS Server)
      - Boot file name: "" (empty)
      - Option 66 (TFTP Server Name): 192.168.1.10 (WDS Server)
      - Option 67 (Bootfile Name): "" (empty)
4.2) altserviceboot (4011) Request
4.3) altserviceboot (4011) Response
      - Boot file: boot\x64\wdsmgfw.efi
      - BCD File: \tmp\x64uefi{...}.bcd
4.4) Read request: boot\x64\wdsmgfw.efi
4.5) DHCP Request
4.6) DHCP ACK
      - Next server: 192.168.1.10 (WDS Server)
      - Boot file name: grub\bootx64.efi
      - BCD File: \tmp\x64uefi{...}.bcd
4.7) Read request: grub\bootx64.efi
4.8) Read request: /grubx64.efi
4.9) Read request: /grub/x86_64-efi/command.lst
4.10) Read request: /grub/x86_64-efi/fs.lst
4.11) Read request: /grub/x86_64-efi/crypto.lst
4.12) Read request: /grub/x86_64-efi/terminal.lst
4.13) Read request: /grub/grub.cfg
4.14) Read request: /grub/Menu/Menu.cfg
4.15) Read request: /grub/x86_64-efi/command.lst
4.16) Read request: /grub/x86_64-efi/fs.lst
4.17) Read request: /grub/x86_64-efi/crypto.lst
4.18) Read request: /grub/x86_64-efi/terminal.lst
4.19) Read request: /grub/unicode.pf2
4.20) Read request: /grub/unicode.pf2
4.21) Read request: /grub/Menu/WinPE.cfg
4.22) Read request: /Boot/x64/bootmgfw.efi
4.23) Read Request: \grub\BCD
      - Error: file not found
4.24) Read Request: \Tmp\x64uefi{9474C15E-088A-447F-90D9-2236AACE1048}.bcd
4.25) Read request: \grub\bootx64.efi
4.26) Read request: \boot\fonts\wgl4_boot.ttf
      - WinPE fail with error code 0xc0000428 (The digital signature for this file couldn’t be verified).

It looks like that the problems occurs in step 4.25 (Read request: \grub\bootx64.efi). It shouldn't get "\grub\bootx64.efi", it should get again "\Boot\x64\bootmgfw.efi" (comparing to the "WinPE boot without GRUB" process).

 

Ive also repeated "WinPE boot with GRUB" but before step 4.25 occurs, I've copied "\Boot\x64\bootmgfw.efi" to "\grub\bootx64.efi". So when the file (step 4.25) "\grub\bootx64.efi" is gotten from the server, actually was the bootmgfw.efi gotten.

When I did this, WinPE booted correctly.

 

Any suggestion to make it work? I can't changed "\grub\bootx64.efi" because GRUB's menu must be shown to the user.

 

Thanks,



#5 Sha0

Sha0

    WinVBlock Dev

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

Posted 28 December 2013 - 07:14 PM

I have captured the network traffic with wireshark.

Cool!
 

3) WinPE boot without GRUB 
   The default boot program for "x64uefi" architecture in WDS was changed to "Boot\x64\bootmgfw.efi".

3.1) DHCP negotiation
      - Next server: 192.168.1.10 (WDS Server)
      - Boot file name: "" (empty)
      - Option 66 (TFTP Server Name): 192.168.1.10 (WDS Server)
      - Option 67 (Bootfile Name): "" (empty)
3.2) altserviceboot (4011) Request
3.3) altserviceboot (4011) Response
      - Boot file: boot\x64\bootmgfw.efi
      - BCD File: \tmp\x64uefi{...}.bcd
3.4) Read request: boot\x64\bootmgfw.efi
3.5) Read Request: \Boot\x64\BCD
      - Error: file not found
3.6) Read Request: \Tmp\x64uefi{9474C15E-088A-447F-90D9-2236AACE1048}.bcd
3.7) Read request: \Boot\x64\bootmgfw.efi
3.8) Read request: \Boot\x64\Images\winpe_amd64_20131030.wim
      - Error: TFTP aborted
3.9) Read request: \Boot\Boot.sdi
      - Error: TFTP aborted
3.10) Read request: \Boot\fonts\wgl4_boot.ttf
3.11) Read request: \Boot\Boot.sdi
3.12) Read request: \Boot\x64\Images\winpe_amd64_20131030.wim
      - WinPE boot successfully 

Above, DHCP does not provide a filename but ProxyDHCP (on UDP 4011) does.
 

4) WinPE boot with GRUB
   The default boot program for "x64uefi" architecture in WDS was changed to "grub\bootx64.efi".

4.1) DHCP negotiation
      - Next server: 192.168.1.10 (WDS Server)
      - Boot file name: "" (empty)
      - Option 66 (TFTP Server Name): 192.168.1.10 (WDS Server)
      - Option 67 (Bootfile Name): "" (empty)
4.2) altserviceboot (4011) Request
4.3) altserviceboot (4011) Response
      - Boot file: boot\x64\wdsmgfw.efi
      - BCD File: \tmp\x64uefi{...}.bcd
4.4) Read request: boot\x64\wdsmgfw.efi

Why wdsmgfw.efi instead of the bootmgfw.efi?
 

4.5) DHCP Request
4.6) DHCP ACK
      - Next server: 192.168.1.10 (WDS Server)
      - Boot file name: grub\bootx64.efi
      - BCD File: \tmp\x64uefi{...}.bcd

Above, there have been both a DHCP as well as a ProxyDHCP response. That is different.
 

4.7) Read request: grub\bootx64.efi
4.8) Read request: /grubx64.efi
4.9) Read request: /grub/x86_64-efi/command.lst
4.10) Read request: /grub/x86_64-efi/fs.lst
4.11) Read request: /grub/x86_64-efi/crypto.lst
4.12) Read request: /grub/x86_64-efi/terminal.lst
4.13) Read request: /grub/grub.cfg
4.14) Read request: /grub/Menu/Menu.cfg
4.15) Read request: /grub/x86_64-efi/command.lst
4.16) Read request: /grub/x86_64-efi/fs.lst
4.17) Read request: /grub/x86_64-efi/crypto.lst
4.18) Read request: /grub/x86_64-efi/terminal.lst
4.19) Read request: /grub/unicode.pf2
4.20) Read request: /grub/unicode.pf2
4.21) Read request: /grub/Menu/WinPE.cfg
4.22) Read request: /Boot/x64/bootmgfw.efi
4.23) Read Request: \grub\BCD
      - Error: file not found
4.24) Read Request: \Tmp\x64uefi{9474C15E-088A-447F-90D9-2236AACE1048}.bcd
4.25) Read request: \grub\bootx64.efi
4.26) Read request: \boot\fonts\wgl4_boot.ttf
      - WinPE fail with error code 0xc0000428 (The digital signature for this file couldn’t be verified).

You have two filename options, which makes things confusing. I don't know if you manually modified the DHCP parameters, but if you did, the DHCP filename is taking precedence over the ProxyDHCP filename because option 60 isn't set.

But regardless of that, it looks like Microsoft wants to redownload the file that was originally booted. This might be a security feature. What you'd probably need to do is to patch the filename option, perhaps using iPXE to do so. Other hacks would be using a specially-modified TFTP service that would hand out (U)EFI GRUB upon the first request, but BootMgFw.efi upon the second request.

#6 Leandro Paulin

Leandro Paulin

    Newbie

  • Members
  • 22 posts
  •  
    Brazil

Posted 02 January 2014 - 09:23 PM

All the tests that I'm doing is in a test environment but it is identical to our production environment.
 
There is a DHCP server (192.168.1.5) and another WDS Server (192.168.1.10).
DHCP Server is Windows 2008 R2 and WDS is Windows Server 2012.
 
When there was only BIOS Legacy, we've configured the DHCP options:
- Boot Server Host Name (66) = 192.168.1.10
- Bootfile Name (067) = pxelinux.0
 
This worked fine for WDS with PXELinux until Windows 8 arrived...  :(  Since then, we need to support PXE UEFI to boot WinPE.
The solution was to still use WDS because it can detect the client architecture (x86, x64, x64uefi) and provide the correct boot program (wdsnbp.com or wdsmgf.efi). By that time, the WDS Server was a Windows Server 2008 R2 and we only could make UEFI PXE work if the option 67 (Bootfile name) was empty. If it continued to be "pxelinux.0" then an UEFI computer won't boot in PXE because pxelinux.0 is not compatible with UEFI. As it was working, we left the DHCP that way.  :thumbup:
We changed to Windows Server 2012 but keeped the DHCP options, so now we have:
- Boot Server Host Name (66) = 192.168.1.10
- Bootfile Name (067) = "" (empty)
 

 

3) WinPE boot without GRUB 

   The default boot program for "x64uefi" architecture in WDS was changed to "Boot\x64\bootmgfw.efi".

I've made a mistake in the description. In the third scenario I've added a "Prestaged device" in WDS (using MAC Address) and for this specific device I've changed the default boot program to "Boot\x64\bootmgfw.efi". So every time time this device booted the WDS server sent "Boot\x64\bootmgfw.efi". That's why there isn't wdsmgfw.efi and only bootmgfw.efi in the PXE process.

 

4) WinPE boot with GRUB
   The default boot program for "x64uefi" architecture in WDS was changed to "grub\bootx64.efi".

4.1) DHCP negotiation
     
- Next server: 192.168.1.10 (WDS Server)
      - Boot file name: "" (empty)
      - Option 66 (TFTP Server Name): 192.168.1.10 (WDS Server)
      - Option 67 (Bootfile Name): "" (empty)
4.2) altserviceboot (4011) Request
4.3) altserviceboot (4011) Response
      - Boot file: boot\x64\wdsmgfw.efi
     
- BCD File: \tmp\x64uefi{...}.bcd
4.4) Read request: boot\x64\wdsmgfw.efi

 

Why wdsmgfw.efi instead of the bootmgfw.efi?

wdsmgfw.efi is always used by WDS, unless a prestaged device has a different boot program... :)

Microsoft says (http://support.micro....com/kb/2012858):

Wdsmgfw.efi
A special NBP developed for use by Windows Deployment Services that serves the following general purposes:
1. Handles prompting the user to press a key to continue PXE boot
2. Pending devices scenarios
3. Network boot referral cases (including use of DHCP options 66 and 67)

4.5) DHCP Request

4.6) DHCP ACK
     
- Next server: 192.168.1.10 (WDS Server)
      - Boot file name: grub\bootx64.efi
     
- BCD File: \tmp\x64uefi{...}.bcd

 

Above, there have been both a DHCP as well as a ProxyDHCP response. That is different.

I've noted that after wdsmgfw.efi (step 4.4) there is another DHCP negotiation (step 4.5) and after that, it is sent the boot program ("grub\bootx64.efi).

 

But regardless of that, it looks like Microsoft wants to redownload the file that was originally booted.

Why not hard coded the file name ?!!! it would work ! ;)

Or use the file name from the BCD File it gets from WDS ("\Tmp\x64uefi{9474C15E-088A-447F-90D9-2236AACE1048}.bcd":

Gerenciador de Inicialização do Windows
---------------------------------------
identificador           {bootmgr}
path                    \Boot\x64\bootmgfw.efi
fontpath                \boot\fonts
inherit                 {dbgsettings}
bootems                 Yes
displayorder            {69c71b09-06b5-49a8-9c0e-9f74f37d9f04}
timeout                 30

Carregador de Inicialização do Windows
--------------------------------------
identificador           {69c71b09-06b5-49a8-9c0e-9f74f37d9f04}
device                  ramdisk=[boot]\Boot\x64\Images\winpe_amd64_20131030.wim,{0c8c0fdd-59f4-4389-be7d-c92c9fb1c0f9}
description             Microsoft Windows PE (x64)
osdevice                ramdisk=[boot]\Boot\x64\Images\winpe_amd64_20131030.wim,{68d9e51c-a129-4ee1-9725-2ab00a957daf}
systemroot              \WINDOWS
detecthal               Yes
winpe                   Yes


#7 Leandro Paulin

Leandro Paulin

    Newbie

  • Members
  • 22 posts
  •  
    Brazil

Posted 07 January 2014 - 08:16 PM

As a workaround I'm trying to boot WinPE in other ways:

 

1) WinPE ISO

I've tried to boot a WinPE ISO using Grub2 but couldn't make it work. I've asked for help in http://reboot.pro/to...oting/?p=181290

 

2) WinPE VHD

Searched for a solution but also couldn't find a way to boot a VHD image in GRUB2.

 

Do I have another option to try to chainload WinPE in a UEFI computer?



#8 Sha0

Sha0

    WinVBlock Dev

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

Posted 08 January 2014 - 01:38 AM

Do I have another option to try to chainload WinPE in a UEFI computer?

I'd mentioned that you can use iPXE with an iPXE script to change the filename or other DHCP options; pretending that the response had come directly from WDS. Then you will fool the Microsoft program into using those options.

#9 Leandro Paulin

Leandro Paulin

    Newbie

  • Members
  • 22 posts
  •  
    Brazil

Posted 08 January 2014 - 01:24 PM

I've forgot to mention but I've looked iPXE up. However I've found some posts saying that it's not stable enough and there are many missing features in UEFI version:

http://forum.ipxe.or...id=9966#pid9966

http://forum.ipxe.or...&highlight=uefi

http://forum.ipxe.or...&highlight=uefi

http://lists.ipxe.or...rch/002345.html

 

After that, I've decided to focus in the ISO or VHD options. As I couldn't find a solution I'm going to look again in iPXE.

 

Thanks for the help,

Leandro



#10 Leandro Paulin

Leandro Paulin

    Newbie

  • Members
  • 22 posts
  •  
    Brazil

Posted 10 January 2014 - 05:25 PM

I've tested iPXE. The latest version that is available in http://git.ipxe.org/ipxe.git doesn't chain other efi image. it's shown an error "Could not boot: No such device" (http://forum.ipxe.or...hread-1087.html).

I've applied the patches in iPXE suggested in http://lists.ipxe.or...ust/002713.html and iPXE could load EFI images.

However, after booting iPXE and chainloading "\Boot\x64\bootmgfw.efi" it ended up with the same error as described in "4) WinPE boot with GRUB".

4.22) Read request: /Boot/x64/bootmgfw.efi

4.23) Read Request: \grub\BCD
          
- Error: file not found
4.24) Read Request: \Tmp\x64uefi{9474C15E-088A-447F-90D9-2236AACE1048}.bcd
4.25) Read request: \grub\bootx64.efi
4.26) Read request: \boot\fonts\wgl4_boot.ttf
          
- WinPE fail with error code 0xc0000428 (The digital signature for this file couldnt be verified).

 

The problem is that WDS's boot process (step 4.25) gets the boot file from the last DHCP negotiation, which is \grub\bootx64.efi (GRUB2) or \iPXE\snponly.efi (iPXE) and not the correct one \Boot\x64\bootmgr.efi.

 

After the results I've tried to change the boot process. Before it was booting GRUB2 then chainload WinPE. I've 

started to search for a solution to first boot the BCD menu from WinPE and then (from BCD) chainload Grub2 (or other bootloader). I've found an old post http://reboot.pro/to...cation-via-bcd/ but without a final solution.

 

Does you know how to do it?

 


  • Mr.JoeM likes this

#11 Mr.JoeM

Mr.JoeM
  • Members
  • 4 posts
  •  
    United States

Posted 10 January 2014 - 08:34 PM

Leandro:

 

Wow! You have gotten a lot further than I have trying to PXE dual-boot. You give me hope that a solution may be close at hand.

 

I have 2 suggestions that are not listed above:

 

#1 -- Disable secure boot in the BIOS, but leave EFI boot on. (Hopefully this is an option) I am hopeful that bootmgfw is just looking at this file for signing purposes.

 

#2 -- Try setting both testsigning and nointegritychecks to ON in the default  BCD files. (Not the ones in /TMP) I have not tried these options, but I know I was able to set debugging to ON with a 2k8R2 WDS server. I would be surprised if 2k12 is different in this regards. I don't know if these options only affect drivers or if the affect boot integrity too. Probably worth a shot.

 

Please let the list know how you get this resolved. I am sure I am not the only person struggling with this too.

 

~joe



#12 Sha0

Sha0

    WinVBlock Dev

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

Posted 11 January 2014 - 06:22 PM

The problem is that WDS's boot process (step 4.25) gets the boot file from the last DHCP negotiation, which is \grub\bootx64.efi (GRUB2) or \iPXE\snponly.efi (iPXE) and not the correct one \Boot\x64\bootmgr.efi.

You need to use an iPXE script to change the DHCP option(s) before booting the Microsoft file. Something like:
#!ipxe
set filename \Boot\x64\bootmgr.efi
set proxydhcp/filename \Boot\x64\bootmgr.efi


#13 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1918 posts
  • Location:Nantes - France
  •  
    France

Posted 11 January 2014 - 06:36 PM

Hi Leandro,

 

Would you be able to share your ipxe build with latest patches?

 

I am playing with uefi + pxe these days and I could definitely use a working snponly.efi :)

 

May be out of topic, but so far I have managed the following :  pxe -> bootfmgfw.efi -> bcd -> boot.wim (winpe4 / x64) in proxydhcp mode.

 

The boot.wim starts loading all fine but I end up with a 0xc0000001 screen.

Any idea?

I know my wim file is fine as it works in legacy mode.

 

Regards,

Erwan



#14 Sha0

Sha0

    WinVBlock Dev

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

Posted 11 January 2014 - 08:24 PM

May be out of topic, but so far I have managed the following :  pxe -> bootfmgfw.efi -> bcd -> boot.wim (winpe4 / x64) in proxydhcp mode.
 
The boot.wim starts loading all fine but I end up with a 0xc0000001 screen.
Any idea?

You can use bcdedit /store \path\to\bcd /enum all to share the contents of that BCD store. Leandro can do the same with the WDS one, then the two can be compared.

I know my wim file is fine as it works in legacy mode.

What is "legacy mode" and how were you booting it?

#15 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1918 posts
  • Location:Nantes - France
  •  
    France

Posted 11 January 2014 - 10:16 PM

You can use bcdedit /store \path\to\bcd /enum all to share the contents of that BCD store. Leandro can do the same with the WDS one, then the two can be compared.
What is "legacy mode" and how were you booting it?

 

Hi Shao,

 

Actually you set me on the right track, my BCD was indeed the issue.

I got myself a new one and now I am going further in the boot process (facing new issues not linked to UEFI).

 

Here below a working BCD (the line in bold was the trick for me) :

 
<code>
Gestionnaire de d‚marrage Windows
---------------------------------
identificateur          {bootmgr}
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {default}
displayorder            {default}
toolsdisplayorder       {memdiag}
timeout                 30
 
Chargeur de d‚marrage Windows
-----------------------------
identificateur          {default}
device                  ramdisk=[boot]\sources\boot.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}
path                    \windows\system32\boot\winload.efi
description             Windows Setup
locale                  en-US
inherit                 {bootloadersettings}
custom:16000060         Yes
osdevice                ramdisk=[boot]\sources\boot.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}
systemroot              \windows
custom:250000c2         1
detecthal               Yes
winpe                   Yes
ems                     No
 
Testeur de m‚moire Windows
--------------------------
identificateur          {memdiag}
device                  boot
path                    \efi\microsoft\boot\memtest.efi
description             Windows Memory Diagnostic
locale                  en-US
inherit                 {globalsettings}
 
ParamŠtres EMS
--------------
identificateur          {emssettings}
bootems                 No
 
ParamŠtres du d‚bogueur
-----------------------
identificateur          {dbgsettings}
debugtype               Serial
debugport               1
baudrate                115200
 
ParamŠtres globaux
------------------
identificateur          {globalsettings}
inherit                 {dbgsettings}
                        {emssettings}
 
ParamŠtres du chargeur de d‚marrage
-----------------------------------
identificateur          {bootloadersettings}
inherit                 {globalsettings}
                        {hypervisorsettings}
 
ParamŠtres de l'hyperviseur
-------------------
identificateur          {hypervisorsettings}
description             Hypervisor Settings
hypervisordebugtype     Serial
hypervisordebugport     1
hypervisorbaudrate      115200
 
Options de p‚riph‚rique
-----------------------
identificateur          {7619dcc8-fafe-11d9-b411-000476eba25f}
ramdisksdidevice        boot
ramdisksdipath          \boot\boot.sdi
</code>
 
Thanks,
Erwan


#16 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1918 posts
  • Location:Nantes - France
  •  
    France

Posted 12 January 2014 - 01:24 PM

Here is how I PXE boot a WINPE on a UEFI computer :

-pxe->bootx64.efi (from windows install dvd)->bcd (pointing to winload.efi)->boot.wim (x64 only)

 

as opposed to a legacy bios computer :

-pxe->pxeboot.n12 (from windows install dvd)-> bootmgr.exe -> bcd (pointing to winload.exe) -> boot.wim

 

Also to be noted and optional : I use option dhcp 252 to point to my custom bcd so that the only thing I change between UEFI and Legacy boot is my boot file name (bootx64.efi vs pxeboot.n12).

 

To make it simple, my boot.wim also comes from my windows install dvd.

I just modified it (thru winpeshl.ini) so that it launches cmd.exe as shell (instead of triggering the windows install) : quick and cheap winpe :)

 

Hope this helps others to perform a Winpe + PXE boot on a UEFI computer.

 

Now, I need IPXE on UEFI to make the whole thing quicker (tftp vs http) and more flexible (menu).

 

Regards,

Erwan



#17 Leandro Paulin

Leandro Paulin

    Newbie

  • Members
  • 22 posts
  •  
    Brazil

Posted 13 January 2014 - 07:09 PM

You need to use an iPXE script to change the DHCP option(s) before booting the Microsoft file. Something like:

#!ipxe
set filename \Boot\x64\bootmgr.efi
set proxydhcp/filename \Boot\x64\bootmgr.efi

Using Grub2 menus, iPXE was chainloaded:

menuentry "iPXE - mod xcat" {
   terminal_output console
   insmod chain
   chainloader /iPXE/snponly_ipxe_xcat.efi
}

after iPXE was loaded I've run the following commands:

iPXE> show filename
net0.dhcp/filename:string = 
iPXE> show proxydhcp/filename
proxydhcp/filename:string = boot\x64\wdsmgfw.efi
iPXE> set filename /boot/x64/bootmgfw.efi
iPXE> set proxydhcp/filename /boot/x64/bootmgfw.efi
iPXE> show filename
filename:string = /boot/x64/bootmgfw.efi
iPXE> show proxydhcp/filename
proxydhcp/filename:string = /boot/x64/bootmgfw.efi
iPXE> chain /boot/x64/bootmgfw.efi

After chaining bootmgfw.efi the WinPE's boot process starts, but again (Step 4.25) it gets "\grub\bootx64.efi"...  :frusty:

So even if I change the boot file name in iPXE, it doesn't make a difference for boomgfw.efi...

 

Wireshark doesn't show anything suggesting that bootmgfw.efi makes a new request to WDS server to find out what is the boot file name. It seems that bootmgfw.efi gets the boot file name from the begging of the PXE boot process:

4.6) DHCP ACK
      - Next server: 192.168.1.10 (WDS Server)
      - Boot file name: grub\bootx64.efi
      - BCD File: \tmp\x64uefi{...}.bcd

To test it, after iPXE booted I've changed the x64uefi boot file in WDS.

wdsutil /set-server /bootprogram:iPXE\snponly_ipxe_xcat.efi /architecture:x64uefi
wdsutil /set-server /N12bootprogram:iPXE\snponly_ipxe_xcat.efi /architecture:x64uefi

Then, in PXE, run "chain /boot/x64/bootmgfw.efi". It's gotten again "\grub\bootx64.efi" and not "snponly_ipxe_xcat.efi" so it doesn't make a new request to WDS to find out the file name during the PXE process.

 

I've look for an "unload" command for the network stack. In grub2 there is "pxe_unload" command (https://www.gnu.org/...#pxe_005funload) but is only for PC BIOS and not UEFI.

I couldn't find a similar command in iPXE.

 

What else can we try?

 

 

Would you be able to share your ipxe build with latest patches?

I've got iPXE from http://git.ipxe.org/ipxe.git and then applied only the changes from http://lists.ipxe.or...ust/002713.html.

If you build iPXE from https://git.ipxe.org...r/xcat/ipxe.git, iPXE has a newer version but in my test environment (vmware) it crashes the VM. My snponly.efi is in http://www.sendspace.com/file/t25406

 

 

#1 -- Disable secure boot in the BIOS, but leave EFI boot on. (Hopefully this is an option) I am hopeful that bootmgfw is just looking at this file for signing purposes.

 

#2 -- Try setting both testsigning and nointegritychecks to ON in the default  BCD files. (Not the ones in /TMP) I have not tried these options, but I know I was able to set debugging to ON with a 2k8R2 WDS server. I would be surprised if 2k12 is different in this regards. I don't know if these options only affect drivers or if the affect boot integrity too. Probably worth a shot.

I'm using only UEFI mode, secure boot is disable. I'm going to try more to investigate if it's possible to boot grub2 after BCD.

 

Thanks guys,



#18 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1918 posts
  • Location:Nantes - France
  •  
    France

Posted 14 January 2014 - 08:48 AM

Hi Leandro,

 

Thanks for the patched iPXE.

Will try to chainload winpe from iPXE later tonight.

 

For now, PXE->MS Bootx64.efi ->BCD (winload.efi) ->Boot.wim (x64) works fine for me, but just like you I need a menu as well.

 

Regards,

Erwan



#19 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1918 posts
  • Location:Nantes - France
  •  
    France

Posted 14 January 2014 - 06:50 PM

For the record and may be it can help to debug / move on further,  

when doing the following :  PXE-> IPXE ->MS Bootx64.efi ->BCD (winload.efi) ->Boot.wim (x64), 

I get just like you "error code 0xc0000428 (The digital signature for this file couldn’t be verified)" .

 

Note that I am also experimenting here with my own PXE server so the issue is not with your WDS I would say

 

/Erwan



#20 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1918 posts
  • Location:Nantes - France
  •  
    France

Posted 14 January 2014 - 08:32 PM

I experiment the same wierd behavior while chainloading WINPE over PXE/UEFI

 

->pxe boot
21:26:24 DHCPd:DISCOVER received, MAC:3C-97-0E-6B-70-C9, XID:82FC6809
21:26:24 DHCPd:OFFER sent, IP:192.168.1.101, XID:82FC6809
21:26:27 DHCPd:REQUEST received, MAC:3C-97-0E-6B-70-C9, XID:82FC6809
21:26:27 DHCPd:ACK sent, IP:192.168.1.101, XID:82FC6809
21:26:27 TFTPd:DoReadFile:ipxe-snponly.efi B:1468 T:0
->ipxe loaded
21:26:30 DHCPd:DISCOVER received, MAC:3C-97-0E-6B-70-C9, XID:127F0B42
21:26:30 DHCPd:iPXE user-class detected
21:26:30 DHCPd:OFFER sent, IP:192.168.1.101, XID:127F0B42
21:26:33 DHCPd:REQUEST received, MAC:3C-97-0E-6B-70-C9, XID:127F0B42
21:26:34 DHCPd:iPXE user-class detected
21:26:34 DHCPd:ACK sent, IP:192.168.1.101, XID:127F0B42
21:26:38 TFTPd:DoReadFile:menu.ipxe B:1432 T:14861
->ipxe menu loaded / lets chainload bootx64.efi
21:26:43 TFTPd:DoReadFile:bootx64.efi B:1432 T:1615712
21:26:44 TFTPd:DoReadFile:BCD B:0 T:262144
21:26:44 TFTPd:DoReadFile:BCD B:0 T:262144
21:26:44 TFTPd:DoReadFile:BCD B:1456 T:262144
->at this point I expect boot.wim to load / not ipxe-snponly.efi !!!
21:26:44 TFTPd:OpenError:Cannot open file "\EFI\en-US\ipxe-snponly.efi.MUI". 
21:26:44 TFTPd:DoReadFile:ipxe-snponly.efi B:0 T:107872
21:26:44 TFTPd:DoReadFile:ipxe-snponly.efi B:1456 T:107872
->loading font to display some text on screen
21:26:44 TFTPd:DoReadFile:wgl4_boot.ttf B:0 T:47452
21:26:44 TFTPd:DoReadFile:wgl4_boot.ttf B:1456 T:47452
21:26:44 TFTPd:DoReadFile:segoe_slboot.ttf B:0 T:77404
21:26:44 TFTPd:DoReadFile:segoe_slboot.ttf B:1456 T:77404
21:26:44 TFTPd:DoReadFile:segmono_boot.ttf B:0 T:36020
21:26:44 TFTPd:DoReadFile:segmono_boot.ttf B:1456 T:36020
->0xc0000428
 
I am not using WDS / ProxyDHCP.
 
My boot sequence : PXE-> IPXE ->MS Bootx64.efi ->BCD (winload.efi) ->Boot.wim (x64)
 
My ipxe script :
set next-server 192.168.1.100
set filename bootx64.efi
chain tftp://${next-server}/${filename}


#21 Sha0

Sha0

    WinVBlock Dev

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

Posted 15 January 2014 - 03:30 AM

after iPXE was loaded I've run the following commands: ...

Use the config command to find out where the option containing \grub\bootx64.efi is. It's got to be in there, somewhere. I guess I forgot where.

#22 Leandro Paulin

Leandro Paulin

    Newbie

  • Members
  • 22 posts
  •  
    Brazil

Posted 15 January 2014 - 12:28 PM

Use the config command to find out where the option containing \grub\bootx64.efi is. It's got to be in there, somewhere. I guess I forgot where.

 

using the config command:

builtin/buildarch = x86_64
builtin/platform = efi
builtin/version = 1.0.0+ (9bdf)
net0.dhcp/gateway = 192.168.1.10
net0.dhcp/ip = 192.168.1.21
net0.dhcp/netmask = 255.255.255.0
net0.dhcp/filename = <not specified>
net0.dhcp/next-server = 192.168.1.11
net0.dhcp/root-path = <not specified>
net0.dhcp/dhcp-server = 192.168.1.10
net0.dhcp/user-class = <not specified>
proxydhcp/filename = boot\x64\wdsmgfw.efi
proxydhcp/next-server = 192.168.1.11
proxydhcp/dhcp-server = 192.168.1.11

@erwan.l

Could you check the config command too in your enviroment?



#23 Leandro Paulin

Leandro Paulin

    Newbie

  • Members
  • 22 posts
  •  
    Brazil

Posted 15 January 2014 - 01:55 PM

YES, It's working !!!!  :yahoo:

 

Thanks to Mr.JoeM for the tips about WinPE options:

#2 -- Try setting both testsigning and nointegritychecks to ON in the default  BCD files. (Not the ones in /TMP) I have not tried these options, but I know I was able to set debugging to ON with a 2k8R2 WDS server. I would be surprised if 2k12 is different in this regards. I don't know if these options only affect drivers or if the affect boot integrity too. Probably worth a shot.

 

I've changed the BCD file and now it works: PXE-->Grub2-->WinPE or PXE-->Grub2-->iPXE-->WinPE.

 

The BCD template file for x64uefi architecture in WDS is in \TFTP_Root\Boot\x64uefi\default.bcd:

Windows Boot Manager
--------------------
identifier              {bootmgr}
path                    \Boot\x64\bootmgfw.efi
fontpath                \boot\fonts
inherit                 {dbgsettings}
bootems                 Yes
timeout                 30

Debugger Settings
-----------------
identifier              {dbgsettings}
debugtype               Serial
debugport               1
baudrate                115200

Device options
--------------
identifier              {68d9e51c-a129-4ee1-9725-2ab00a957daf}
ramdisksdidevice        boot
ramdisksdipath          \Boot\Boot.SDI
ramdisktftpblocksize    1456
ramdisktftpwindowsize   4
ramdisktftpvarwindow    Yes

Add the option nointegritychecks and set it to yes:

bcdedit.exe /store TFTP_Root\Boot\x64uefi\default.bcd /set {bootmgr} nointegritychecks yes

Then the default BCD will be:

Windows Boot Manager
--------------------
identifier              {bootmgr}
path                    \Boot\x64\bootmgfw.efi
fontpath                \boot\fonts
inherit                 {dbgsettings}
bootems                 Yes
nointegritychecks       Yes
timeout                 30

Debugger Settings
-----------------
identifier              {dbgsettings}
debugtype               Serial
debugport               1
baudrate                115200

Device options
--------------
identifier              {68d9e51c-a129-4ee1-9725-2ab00a957daf}
ramdisksdidevice        boot
ramdisksdipath          \Boot\Boot.SDI
ramdisktftpblocksize    1456
ramdisktftpwindowsize   4
ramdisktftpvarwindow    Yes

Restart the WDS service and then the BCD files for x64uefi in the /tmp folder will have the option nointegritychecks set.

Example for x64uefi{3A3550FE-71A6-4F10-B0E8-B3E6BE5575C9}.bcd:

Windows Boot Manager
--------------------
identifier              {bootmgr}
path                    \Boot\x64\bootmgfw.efi
fontpath                \boot\fonts
inherit                 {dbgsettings}
bootems                 Yes
nointegritychecks       Yes
displayorder            {69c71b09-06b5-49a8-9c0e-9f74f37d9f04}
timeout                 30

Windows Boot Loader
-------------------
identifier              {69c71b09-06b5-49a8-9c0e-9f74f37d9f04}
device                  ramdisk=[boot]\Boot\x64\Images\winpe_amd64_20131030.wim,{0c8c0fdd-59f4-4389-be7d-c92c9fb1c0f9}
description             Microsoft Windows PE (x64)
osdevice                ramdisk=[boot]\Boot\x64\Images\winpe_amd64_20131030.wim,{68d9e51c-a129-4ee1-9725-2ab00a957daf}
systemroot              \WINDOWS
detecthal               Yes
winpe                   Yes

Debugger Settings
-----------------
identifier              {dbgsettings}
debugtype               Serial
debugport               1
baudrate                115200

Device options
--------------
identifier              {0c8c0fdd-59f4-4389-be7d-c92c9fb1c0f9}
inherit                 {68d9e51c-a129-4ee1-9725-2ab00a957daf}
ramdiskmcenabled        No
ramdiskmctftpfallback   Yes

Device options
--------------
identifier              {68d9e51c-a129-4ee1-9725-2ab00a957daf}
ramdisksdidevice        boot
ramdisksdipath          \Boot\Boot.SDI
ramdisktftpblocksize    1456
ramdisktftpwindowsize   4
ramdisktftpvarwindow    Yes

Changing that option in BCD, it's possible to chain WinPE from Grub2 using menus:

menuentry "WinPE" {
   terminal_output console
   insmod chain
   chainloader /Boot/x64/bootmgfw.efi
}

Or from iPXE from the console (without changing iPXE's settings):

iPXE> chain /boot/x64/bootmgfw.efi

WinPE boots correctly but in Wireshark the PXE boot process still was the "\grub\bootx64.efi" file sent in step 4.25. However, it looks like that it doesn't matter if it's not sent "\boot\x64\bootmgfw.efi".

 

@erwan.l

Can you modify your BCD file and test it? Let us know the results to see if this is a solution to chain WinPE in UEFI mode.

 

Thanks everyone for helping,

Leandro Paulin



#24 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1918 posts
  • Location:Nantes - France
  •  
    France

Posted 15 January 2014 - 02:45 PM

Hi Leandro,

 

Will test it this evening.

 

For ipxe and to ensure it gets the file from the TFTP and not locally, try the below script:

 

set next-server 192.168.1.100 (adapt the IP obviously)
set filename bootx64.efi
chain tftp
://${next-server}/${filename}

 

Regards,

Erwan



#25 Leandro Paulin

Leandro Paulin

    Newbie

  • Members
  • 22 posts
  •  
    Brazil

Posted 15 January 2014 - 06:02 PM

I've used:

set next-server 192.168.1.11
set filename boot/x64/bootmgfw.efi
chain tftp://${next-server}/${filename}

and it's using TFTP.

 

I've also tried HTTP "chain http://${next-server}/${filename}" but only bootmgfw.efi was loaded using HTTP, the other files were TFTP.






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users