WinPE (wimboot) BIOS and UEFi

http://www.mistyrebootfiles.altervista.org/documents/TinyPXEServer/files/winpe_wimboot.htm

wimboot version 2.5.2 was used in the tests carried out below and is included in the Tiny PXE Server version 1.0.0.20 (dated 12/2/2017 (19:29)) download package. The most recent wimboot version can be downloaded from here. The wimboot and wimboot_architecture pages on the iPXE site contain detailed information about usage.

All references to wimboot in this page refer to the wimboot module developed by Michael Brown – this is not to be confused with the wimboot feature introduced in Windows 8.1 (a method used to boot a full Windows OS from files within a compressed .wim image on a local drive).

wimboot features –

Windows Preinstallation Environment (WinPE) and file dependencies required for PXE booting WinPE are covered in detail in the WinPE page of this document – please read the WinPE page first, prior to this page.

Sections in this page include –

• wimboot Commands/Syntax
• Required Files
• Virtual Names
• wimboot Virtual Filesystem and Paths
• iPXE Example Script (BIOS)
• iPXE Example Script (UEFI)
• iPXE Example Script (BIOS and UEFI)
• Possible Problems and Error Messages
• Using alternative .wim or BCD files
• wimboot Memory Usage
• pxelinux settings
• grub4dos settings
• iPXE settings

wimboot Commands/Syntax

The wimboot page lists several commands that can be passed to wimboot (e.g. using the iPXE kernel command) –

• pause (e.g. kernel wimboot pause) – “…This will instruct wimboot to wait for a keypress before booting Windows, to give you a further opportunity to observe any messages that may be displayed. …”. This command may be useful for troubleshooting.

• index=# (e.g. kernel wimboot index=2) – “…A WIM file can contain multiple bootable images. You can use the index=<N> command-line option to select the image to be booted….”.

• rawbcd (e.g. kernel wimboot rawbcd) – “…wimboot will automatically patch standard BIOS-compatible boot configuration data (BCD) files to allow them to be used on UEFI systems, by changing all occurrences of the string ”.exe” to ”.efi”. You can disable this behaviour by using the rawbcd command-line option….”

Required Files

As a minimum, the following files are required for booting WinPE via wimboot –

• wimboot – the wimboot executable.

• bootmgr.exe – Windows Boot Manager. This file may be extracted by wimboot on the fly (from *.wim – see below). NOTE – for use on Client systems with BIOS Firmware, or on UEFI systems booting in CSM mode.

• bootx64.efi – Windows Boot Manager. This file may be extracted by wimboot on the fly (from *.wim – see below). NOTE – for use on Client systems with UEFI Firmware.

• BCD – Boot Configuration Data. A registry hive containing boot settings used to load the Windows NT6.* operating system – in this case WinPE.

• *.sdi – System Deployment Image. This file (typically boot.sdi) is used to create the RAMDISK and filesystem used to mount the files in *.wim.

• *.wim – Windows Image File (typically boot.wim or winpe.wim or winre.wim). This is a compressed archive containing the WinPE Operating System files.

The following paths (relative to the HTTP root directory) are used in the instructions below –

• \wimboot
• \bootmgr.exe
• \bootx64.efi
• \Boot\BCD
• \Boot\boot.sdi
• \Boot\boot.wim

NOTE – on 32-bit UEFI systems, references to the UEFI boot file bootx64.efi will need to be replaced with \bootia32.efi.

Virtual Names

The required WinPE files are (down)loaded using either the imgfetch, initrd or module commands. These files are mapped to a Virtual Filesystem using a Virtual Name – refer to the wimboot Virtual Filesystem and Paths section for more information about the Virtual Filesystem. The Virtual Name can be the same as the original filename, or a different name can be used – a Virtual Name must however be specified. There are limited scenarios in which a filename will need to be mapped using a different Virtual Name – this concept is covered in more detail in the Using alternative .wim or BCD files section of this page.

A typical example for loading a file on Clients with BIOS Firmware uses the following syntax –

• initrd [path]   [virtual_name]

The syntax for Clients with UEFI Firmware is slightly different, either one of the examples below can be used –

• initrd –name [virtual_name]   [path]
• initrd -n [virtual_name]   [path]

Where on both BIOS and UEFI systems –

• path – Filename (with path) to be loaded. For example, to load BOOTMGR.EXE located at the root of the HTTP server with IP address 192.168.1.1 – use http://192.168.1.1/BOOTMGR.EXE.

• virtual_name – name that the file specified in the path will be mapped as on the wimboot Virtual Filesystem.

Putting these elements together, on Client systems with BIOS Firmware the relevant line in the iPXE script could use one of the following to map the file BOOTMGR.EXE using the virtual name bootmgr.exe –

• initrd http://192.168.1.1/BOOTMGR.EXE     bootmgr.exe
• initrd http://${dhcp-server}/BOOTMGR.EXE     bootmgr.exe
• initrd http://${next-server}/BOOTMGR.EXE     bootmgr.exe

Putting these elements together, on Client systems with UEFI Firmware the relevant line in the iPXE script could use one of the following to map the file BOOTX64.EFI using the virtual name bootx64.efi –

• initrd –name bootx64.efi   http://192.168.1.1/BOOTX64.EFI
• initrd –name bootx64.efi   http://${dhcp-server}/BOOTX64.EFI
• initrd –name bootx64.efi   http://${next-server}/BOOTX64.EFI
• initrd -n bootx64.efi   http://192.168.1.1/BOOTX64.EFI
• initrd -n bootx64.efi   http://${dhcp-server}/BOOTX64.EFI
• initrd -n bootx64.efi   http://${next-server}/BOOTX64.EFI

NOTE – Filenames and Virtual Names are not case sensitive – UPPERCASE and lowercase names have been used for bootmgr.exe and bootx64.efi in the examples above to illustrate how wimboot uses Virtual Names.

wimboot Virtual Filesystem and Paths

wimboot maps any files (down)loaded using either the imgfetch, initrd or module commands to a Virtual Filesystem. Any file loaded by wimboot will be mapped to multiple locations on this wimboot Virtual Filesystem. At the time of writing these locations include –

• \
• \Boot
• \Boot\Fonts
• \Boot\Resources
• \Sources
• \EFI
• \EFI\Boot
• \EFI\Microsoft
• \EFI\Microsoft\Boot

Taking the command initrd http://192.168.1.1/BOOTMGR.EXE bootmgr.exe from the earlier example, the actual file BOOTMGR.EXE will be mapped as the virtual file bootmgr.exe in ALL of the following (virtual) paths –

• \bootmgr.exe
• \Boot\bootmgr.exe
• \Boot\Fonts\bootmgr.exe
• \Boot\Resources\bootmgr.exe
• \Sources\bootmgr.exe
• \EFI\bootmgr.exe
• \EFI\Boot\bootmgr.exe
• \EFI\Microsoft\bootmgr.exe
• \EFI\Microsoft\Boot\bootmgr.exe

iPXE Example Script (BIOS)

Sample iPXE script –

#!ipxe
kernel http://192.168.1.1/wimboot pause
initrd http://192.168.1.1/BOOTMGR.EXE      bootmgr.exe
initrd http://192.168.1.1/BOOT/BCD         bcd
initrd http://192.168.1.1/BOOT/BOOT.SDI    boot.sdi
initrd http://192.168.1.1/BOOT/BOOT.WIM    boot.wim
boot

Breaking down the commands listed in the sample script above –

• kernel http://192.168.1.1/wimboot pause – load wimboot (from the root HTTP folder on the system with IP address 192.168.1.1) and run it with the pause command. .

• initrd http://192.168.1.1/BOOTMGR.EXE bootmgr.exe – load BOOTMGR.EXE (from the root HTTP folder on the system with IP address 192.168.1.1) and map it using the Virtual Name bootmgr.exe on the wimboot Virtual Filesystem.

• initrd http://192.168.1.1/BOOT/BCD bcd – load BCD (from the HTTP server with IP address 192.168.1.1) and map it using the Virtual Name bcd on the wimboot Virtual Filesystem.

• initrd http://192.168.1.1/BOOT/BOOT.SDI boot.sdi – load BOOT.SDI (from the HTTP server with IP address 192.168.1.1) and map it using the Virtual Name boot.sdi on the wimboot Virtual Filesystem.

• initrd http://192.168.1.1/BOOT/BOOT.WIM boot.wim – load BOOT.WIM (from the HTTP server with IP address 192.168.1.1) and map it using the Virtual Name boot.wim on the wimboot Virtual Filesystem.

iPXE Example Script (UEFI)

Sample iPXE script –

#!ipxe
kernel http://192.168.1.1/wimboot pause
initrd –name bootx64.efi   http://192.168.1.1/BOOTX64.EFI
initrd –name bcd           http://192.168.1.1/BOOT/BCD
initrd –name boot.sdi      http://192.168.1.1/BOOT/BOOT.SDI
initrd –name boot.wim      http://192.168.1.1/BOOT/BOOT.WIM
boot

Breaking down the commands listed in the sample script above –

• kernel http://192.168.1.1/wimboot pause – load wimboot (from the root HTTP folder on the system with IP address 192.168.1.1) and run it with the pause command. .

• initrd –name bootx64.efi http://192.168.1.1/BOOTX64.EFI – load BOOTX64.EFI (from the root HTTP folder on the system with IP address 192.168.1.1) and map it using the Virtual Name bootx64.efi on the wimboot Virtual Filesystem.

• initrd –name bcd http://192.168.1.1/BOOT/BCD – load BCD (from the HTTP server with IP address 192.168.1.1) and map it using the Virtual Name bcd on the wimboot Virtual Filesystem.

• initrd –name boot.sdi http://192.168.1.1/BOOT/BOOT.SDI – load BOOT.SDI (from the HTTP server with IP address 192.168.1.1) and map it using the Virtual Name boot.sdi on the wimboot Virtual Filesystem.

• initrd –name boot.wim http://192.168.1.1/BOOT/BOOT.WIM – load BOOT.WIM (from the HTTP server with IP address 192.168.1.1) and map it using the Virtual Name boot.wim on the wimboot Virtual Filesystem.

iPXE Example Script (BIOS and UEFI)

It is possible to use the same script on BIOS and UEFI systems by specifying the Virtual Name using the –name (or -n) switch before the PATH, and also after the PATH. Use the syntax –

• initrd –name [virtual_name]   [path]   [virtual_name]
• initrd -n [virtual_name]   [path]   [virtual_name]

E.g. –

#!ipxe
kernel http://192.168.1.1/wimboot pause
initrd -n bootmgr.exe   http://192.168.1.1/BOOTMGR.EXE     bootmgr.exe ||
initrd -n bootx64.efi   http://192.168.1.1/BOOTX64.EFI     bootx64.efi ||
initrd -n bcd           http://192.168.1.1/BOOT/BCD        bcd
initrd -n boot.sdi      http://192.168.1.1/BOOT/BOOT.SDI   boot.sdi
initrd -n boot.wim      http://192.168.1.1/BOOT/BOOT.WIM   boot.wim
boot

In the above example, the || operator (following the 3rd and 4th lines) is specified to proceed to the next line if the command fails (e.g. if bootmgr.exe or bootx64.efi is missing).

On UEFI systems, bootmgr.exe will be loaded to the Virtual Filesystem, but will be ignored and bootx64.efi will be loaded and booted.

On BIOS systems, bootx64.efi will be loaded to the Virtual Filesystem, but will be ignored and bootmgr.exe will be loaded and booted.

See here for a sample script configured to load the correct boot file based on platform firmware.

Possible Problems and Error Messages

The most likely problems, assuming that all of the required files were loaded successfully, are incorrect filename(s)/path(s) in either the Virtual Filestem and/or the BCD (Boot Configuration Data) store.

• Error Message – “Info: The Boot Configuration Data for your PC is missing or contains errors.”

• Error Message – “Info: A required device isn’t connected or can’t be accessed.”

Error Message – “Info: The Boot Configuration Data for your PC is missing or contains errors.”

The filename and path for the BCD store is hardcoded in bootmgr.exe and bootx64.efi. If the BCD store was mapped with a Virtual Name (see here) other than BCD it will not be found. Error message screenshot –

Fix – map the BCD store using the Virtual Name BCD. The following example demonstrates how to map the BCD store http://192.168.1.1/BCD2 using the Virtual Name BCD –

• initrd –name BCD http://192.168.1.1/BCD2 BCD

Error Message – “Info: A required device isn’t connected or can’t be accessed.”

This error could be the result of a required file (*.sdi or *.wim – or both) not being found if the hardcoded path in the BCD store does not match one of the paths on the wimboot Virtual Filesystem (see here). Taking a *.wim file as an example, assuming the Filename for the *.wim file is boot.wim, the path to this file in your BCD store MUST be one of the following –

• \boot.wim
• \Boot\boot.wim
• \Boot\Fonts\boot.wim
• \Boot\Resources\boot.wim
• \Sources\boot.wim
• \EFI\boot.wim
• \EFI\Boot\boot.wim
• \EFI\Microsoft\boot.wim
• \EFI\Microsoft\Boot\boot.wim

To check the path(s) in your BCD store (e.g. C:\pxesrv\files\boot\BCD), use the following bcdedit command –

• bcdedit /store “C:\pxesrv\files\boot\BCD” /enum ALL

Output from running the above command on the BCD store available here –

Windows Boot Manager
——————–
identifier              {bootmgr}
device                  boot
description             Boot Manager
displayorder            {947d969e-f6ee-11e6-8274-ec55f9effba0}
timeout                 20

Windows Boot Loader
——————-
identifier              {947d969e-f6ee-11e6-8274-ec55f9effba0}
device                  ramdisk=[boot]\boot\boot.wim,{940fe9c2-f6ee-11e6-8274-ec55f9effba0}
path                    \windows\system32\winload.exe
description             WinPE (wimboot)
nointegritychecks       Yes
osdevice                ramdisk=[boot]\boot\boot.wim,{940fe9c2-f6ee-11e6-8274-ec55f9effba0}
systemroot              \Windows
detecthal               Yes
winpe                   Yes

Device options
————–
identifier              {940fe9c2-f6ee-11e6-8274-ec55f9effba0}
ramdisksdidevice        boot
ramdisksdipath          \boot\boot.sdi

And the relevant section for the *.wim file (note the path is specified in the device and osdevice lines as \boot\boot.wim) –

Windows Boot Loader
——————-
identifier              {947d969e-f6ee-11e6-8274-ec55f9effba0}
device                  ramdisk=[boot]\boot\boot.wim,{940fe9c2-f6ee-11e6-8274-ec55f9effba0}
path                    \windows\system32\winload.exe
description             WinPE (wimboot)
nointegritychecks       Yes
osdevice                ramdisk=[boot]\boot\boot.wim,{940fe9c2-f6ee-11e6-8274-ec55f9effba0}
systemroot              \Windows
detecthal               Yes
winpe                   Yes

The Virtual Names for all required files must also match the Filename specified in the BCD store. If the BCD store specifies the *.wim file with path as \sources\boot.wim then your *.wim file must be loaded with the Virtual Name boot.wim. If the BCD store specifies the *.wim file with path as sources\x86.wim then your *.wim file must be loaded with the Virtual Name x86.wim.

Error message screenshot –

Fix – map the *.wim file using the Virtual Name boot.wim and map the *.sdi file using the Virtual Name boot.sdi and use the BCD store available here. The script used to create this BCD store is available here. The paths match paths on the wimboot Virtual Filesystem and should work on BIOS and UEFI Client systems (edit IP_ADDRESS and any PATHS to reflect your own setup).

Example script –

#!ipxe
kernel http://IP_ADDRESS/wimboot pause
initrd -n bootmgr.exe   http://IP_ADDRESS/bootmgr.exe     bootmgr.exe ||
initrd -n bootx64.efi   http://IP_ADDRESS/bootx64.efi     bootx64.efi ||
initrd -n BCD           http://IP_ADDRESS/BOOT/BCD        BCD
initrd -n boot.sdi      http://IP_ADDRESS/PATH/my.sdi     boot.sdi
initrd -n boot.wim      http://IP_ADDRESS/PATH/my.wim     boot.wim
boot

Using alternative .wim or BCD files

Remember that any files specified in the initrd lines of wimboot scripts must specify a virtual name. Whilst the Virtual Name can be identical to the actual Filename, it can be different.

This allows multiple versions of .wim and .sdi files to be booted without having to create different BCD stores (or adding multiple entries to one BCD store). The following script helps to demonstrate this (note that the BCD store (here) with contents…

indows Boot Manager
——————–
identifier         {bootmgr}
device             boot
description        Boot Manager
displayorder       {6376a0ba-f3d4-11e6-8264-ec55f9effba0}
timeout            20

Windows Boot Loader
——————-
identifier         {6376a0ba-f3d4-11e6-8264-ec55f9effba0}
device             ramdisk=[boot]\boot\boot.wim,{63101aca-f3d4-11e6-8264-ec55f9effba0}
path               \windows\system32\winload.exe
description        WinPE (wimboot)
osdevice           ramdisk=[boot]\boot\boot.wim,{63101aca-f3d4-11e6-8264-ec55f9effba0}
systemroot         \Windows
detecthal          Yes
winpe              Yes

Device options
————–
identifier         {63101aca-f3d4-11e6-8264-ec55f9effba0}
ramdisksdidevice   boot
ramdisksdipath     \boot\boot.sdi

…and entries for boot.wim and boot.sdi is used in the test below.

#!ipxe
kernel http://192.168.1.1/wimboot pause
initrd -n bootmgr.exe   http://192.168.1.1/BOOTMGR.EXE     bootmgr.exe ||
initrd -n bootx64.efi   http://192.168.1.1/BOOTX64.EFI     bootx64.efi ||
initrd -n bcd           http://192.168.1.1/BOOT/BCD        bcd
initrd -n boot.sdi      http://192.168.1.1/BOOT/x86.sdi   boot.sdi
initrd -n boot.wim      http://192.168.1.1/BOOT/x86.wim   boot.wim
boot

Screenshot from running the above script –

We can see from the above screenshot that x86.wim (http://192.168.1.1/BOOT/x86.wim) was loaded successfully – after control was passed to wimboot the file was found as boot.wim (wimboot output – “…found WIM file boot.wim“).

The same method can be used to load different BCD stores – e.g.

initrd –name BCD http://192.168.1.1/BOOT/BCD_uefi    BCD

wimboot Memory Usage

The wimboot documentation states –

I’m not sure how accurate this statement is, as on the text system there were significant benefits in terms of RAM usage when using the native Windows PE network bootstrap program (pxeboot.n12 – see here) instead of wimboot.

The screenshot below shows total memory available on the test system (VMWare Player with 1GB of RAM) when WinPE was loaded using pxeboot.n12 (Total RAM = 1022 MB) –

The screenshot below shows total memory available on the test system (the same VMWare Player system with 1GB of RAM) when WinPE was loaded using wimboot (Total RAM = 818 MB) –

The difference in Total RAM between the two systems is 204 MB – with the wimboot system having less RAM available. The difference in RAM is approximately the size of the boot.wim file containing WinPE – this is similar to RAM usage with memdisk – whilst it may no longer be possible to access the emulated disk (the wim mapped to memory) from the booted operating system if the kernel runs in protected mode, the RAM it occupies will remain in use – it’s no longer available to the operating system.

pxelinux settings

It is not possible to successfully boot WinPE via wimboot from PXELINUX version 4.06 – iPXE must be chainloaded and then used to boot wimboot.

In addition to the WinPE files listed in the Required Files section, ensure that the following files are copied to your Tiny PXE Server root directory –

• C:\pxesrv\files\pxelinux.0
• C:\pxesrv\files\menu.c32
• C:\pxesrv\files\pxelinux.cfg\default
• C:\pxesrv\files\ipxe.lkrn (iPXE Linux Kernel)
• C:\pxesrv\files\wimboot_lkrn.txt (iPXE script – see below)

Add the following to C:\pxesrv\files\pxelinux.cfg\default (create this file if required) –

LABEL wimboot1
MENU LABEL wimboot (iPXE)
KERNEL ipxe.lkrn
APPEND initrd=wimboot_lkrn.txt

LABEL wimboot1<br /><br /><br /><br /> MENU LABEL wimboot (iPXE)<br /><br /><br /><br /> KERNEL ipxe.lkrn<br /><br /><br /><br /> APPEND initrd=wimboot_lkrn.txt<br /><br /><br /><br />

Contents of C:\pxesrv\files\wimboot_lkrn.txt (create this file if required) –

#!ipxe
dhcp net0 && echo IP address: ${net0/ip} ; echo Subnet mask: ${net0/netmask}
set boot-url http://${dhcp-server}
kernel ${boot-url}/wimboot pause
initrd -n bootmgr.exe   ${boot-url}/BOOTMGR.EXE     bootmgr.exe ||
initrd -n bootx64.efi   ${boot-url}/BOOTX64.EFI     bootx64.efi ||
initrd -n bcd           ${boot-url}/BOOT/BCD        bcd
initrd -n boot.sdi      ${boot-url}/BOOT/BOOT.SDI   boot.sdi
initrd -n boot.wim      ${boot-url}/BOOT/BOOT.WIM   boot.wim
boot

NOTE – remember to change set boot-url http://${dhcp-server} if using ProxyDHCP. Also note that as we are chainloading iPXE we need to run the dhcp command to configure the network interface before running the other commands.

Some newer (than PXELINUX 4.06) versions of PXELINUX can run wimboot directly without chainloading iPXE – see here and here. The following menu entry was tested using PXELINUX version 6.03 –

LABEL wimboot2
MENU LABEL wimboot (pxelinux)
com32 linux.c32
append wimboot initrdfile=bootmgr.exe,boot/BCD,boot/boot.sdi,boot/boot.wim

PXELINUX version 6.03 also supports mapping files with different filenames (refer to the Using alternative .wim or BCD files section). Syntax is initrdfile=PATH_FILE@MAP_AS – to map boot\x86.wim as boot.wim, use initrdfile=boot\x86.wim@boot.wim. E.g. –

LABEL wimboot2
MENU LABEL wimboot (pxelinux)
com32 linux.c32
append wimboot initrdfile=bootmgr.exe@bootmgr.exe,boot/BCD@BCD,boot/boot.sdi@boot.sdi,boot/x86.wim@boot.wim

Click on one of the following for sample config.ini settings (edit to reflect your own setup) –

• DHCP – here
• Proxy DHCP – here

grub4dos settings

It is not possible to successfully boot WinPE via wimboot from grub4dos using the version included in the Tiny PXE Server download – iPXE must be chainloaded and then used to boot wimboot.

In addition to the WinPE files listed in the Required Files section, ensure that the following files are copied to your Tiny PXE Server root directory –

• C:\pxesrv\files\grldr
• C:\pxesrv\files\menu.lst\default
• C:\pxesrv\files\ipxe.lkrn (iPXE Linux Kernel)
• C:\pxesrv\files\wimboot_lkrn.txt (iPXE script – see below)

Add the following to C:\pxesrv\files\menu.lst\default (create this file if required) –

title wimboot (iPXE)
pxe keep
kernel (pd)/ipxe.lkrn
initrd (pd)/wimboot_lkrn.txt

Contents of C:\pxesrv\files\wimboot_lkrn.txt (create this file if required) –

#!ipxe
dhcp net0 && echo IP address: ${net0/ip} ; echo Subnet mask: ${net0/netmask}
set boot-url http://${dhcp-server}
kernel ${boot-url}/wimboot pause
initrd -n bootmgr.exe   ${boot-url}/BOOTMGR.EXE     bootmgr.exe ||
initrd -n bootx64.efi   ${boot-url}/BOOTX64.EFI     bootx64.efi ||
initrd -n bcd           ${boot-url}/BOOT/BCD        bcd
initrd -n boot.sdi      ${boot-url}/BOOT/BOOT.SDI   boot.sdi
initrd -n boot.wim      ${boot-url}/BOOT/BOOT.WIM   boot.wim
boot

NOTE – remember to change set boot-url http://${dhcp-server} if using ProxyDHCP. Also note that as we are chainloading iPXE we need to run the dhcp command to configure the network interface before running the other commands.

Some newer versions of Grub4dos are reported to run wimboot directly without chainloading iPXE – see here. This feature was added in Grub4dos version 0.4.5c-2014-11-10, however I have not had any success in my tests. Reported menu syntax –

title wimboot (grldr)
kernel /wimboot
initrd @bcd=/boot/bcd @boot.sdi=/boot/boot.sdi @bootmgr.exe=/bootmgr.exe @boot.wim=/boot/boot.wim

Click on one of the following for config.ini settings (edit to reflect your own setup) –

• DHCP – here
• Proxy DHCP – here

iPXE settings

Remember to ensure that the required files are copied to your Tiny PXE Server root directory –

• C:\pxesrv\files\ipxe.pxe (or C:\pxesrv\files\ipxe-undionly.kpxe)
• C:\pxesrv\files\ipxe_menu.txt

Add the following to the menu section of C:\pxesrv\files\ipxe_menu.txt (create this file if required) –

item wimboot1      wimboot

Add the following to the menu options section of C:\pxesrv\files\ipxe_menu.txt –

:wimboot1
kernel ${boot-url}/wimboot pause
initrd -n bootmgr.exe   ${boot-url}/BOOTMGR.EXE     bootmgr.exe ||
initrd -n bootx64.efi   ${boot-url}/BOOTX64.EFI     bootx64.efi ||
initrd -n bcd           ${boot-url}/BOOT/BCD        bcd
initrd -n boot.sdi      ${boot-url}/BOOT/BOOT.SDI   boot.sdi
initrd -n boot.wim      ${boot-url}/BOOT/BOOT.WIM   boot.wim
boot

E.g. –

#!ipxe
#============== Set Variables ===============
set boot-url http://${dhcp-server}

#================ Main Menu =================
menu iPXE boot menu
item wimboot1      wimboot
choose target && goto ${target}

#============ Main Menu Options =============
:wimboot1
kernel ${boot-url}/wimboot pause
initrd -n bootmgr.exe   ${boot-url}/BOOTMGR.EXE     bootmgr.exe ||
initrd -n bootx64.efi   ${boot-url}/BOOTX64.EFI     bootx64.efi ||
initrd -n bcd           ${boot-url}/BOOT/BCD        bcd
initrd -n boot.sdi      ${boot-url}/BOOT/BOOT.SDI   boot.sdi
initrd -n boot.wim      ${boot-url}/BOOT/BOOT.WIM   boot.wim
boot

NOTE – remember to change set boot-url http://${dhcp-server} if using ProxyDHCP.

Click on one of the following for config.ini settings (edit to reflect your own setup) –

• DHCP – here
• Proxy DHCP – here

iPXE Scripts

As an alternative to a menu, use a script to automatically load wimboot. Specify the script using the altfilename option in config.ini. NOTE – remember to change set boot-url http://${dhcp-server} if using ProxyDHCP.

Sample iPXE script –

#!ipxe
set boot-url http://${dhcp-server}
kernel ${boot-url}/wimboot pause
initrd -n bootmgr.exe   ${boot-url}/BOOTMGR.EXE     bootmgr.exe ||
initrd -n bootx64.efi   ${boot-url}/BOOTX64.EFI     bootx64.efi ||
initrd -n bcd           ${boot-url}/BOOT/BCD        bcd
initrd -n boot.sdi      ${boot-url}/BOOT/BOOT.SDI   boot.sdi
initrd -n boot.wim      ${boot-url}/BOOT/BOOT.WIM   boot.wim
boot

Sample iPXE script configured to load the correct boot file based on platform firmware –

#!ipxe
set boot-url http://${dhcp-server}
kernel ${boot-url}/wimboot pause
iseq ${platform} pcbios && initrd -n bootmgr.exe  ${boot-url}/BOOTMGR.EXE  bootmgr.exe ||
iseq ${platform} efi    && initrd -n bootx64.efi  ${boot-url}/BOOTX64.EFI  bootx64.efi ||
initrd -n bcd           ${boot-url}/BOOT/BCD        bcd
initrd -n boot.sdi      ${boot-url}/BOOT/BOOT.SDI   boot.sdi
initrd -n boot.wim      ${boot-url}/BOOT/BOOT.WIM   boot.wim
boot

Document date – 28^th February 2017(DRAFT)

Поделиться: