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 –
“…wimboot is a boot loader for Windows Imaging Format (.wim) files. It enables you to boot a Windows PE (WinPE) environment from a RAM disk, without wasting the memory used for the RAM disk image.
You can use wimboot with iPXE to boot Windows PE via HTTP. With a Gigabit Ethernet network, a typical 200MB WinPE image should download in less than two seconds…. wimboot allows you to use a single procedure and set of files to boot under both BIOS and UEFI environments…”
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.
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 –
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 –
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 –
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.
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 –
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.”
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 –
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).
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…
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.
“…boot a Windows PE (WinPE) environment from a RAM disk, without wasting the memory used for the RAM disk image…”
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
Contents of C:\pxesrv\files\wimboot_lkrn.txt (create this file if required) –
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 –
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. –
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) –
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 –
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.
Мы используем файлы cookie на нашем веб-сайте, запоминая ваши предпочтения и повторные посещения. Нажимая «Принять», вы соглашаетесь на использование ВСЕХ файлов cookie.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Апр 6 2017
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 –
“…wimboot is a boot loader for Windows Imaging Format (.wim) files. It enables you to boot a Windows PE (WinPE) environment from a RAM disk, without wasting the memory used for the RAM disk image.
You can use wimboot with iPXE to boot Windows PE via HTTP. With a Gigabit Ethernet network, a typical 200MB WinPE image should download in less than two seconds…. wimboot allows you to use a single procedure and set of files to boot under both BIOS and UEFI environments…”
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
The wimboot page lists several commands that can be passed to wimboot (e.g. using the iPXE kernel command) –
Required Files
As a minimum, the following files are required for booting WinPE via wimboot –
The following paths (relative to the HTTP root directory) are used in the instructions below –
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 –
The syntax for Clients with UEFI Firmware is slightly different, either one of the examples below can be used –
Where on both BIOS and UEFI systems –
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 –
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 –
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 –
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 –
iPXE Example Script (BIOS)
Sample iPXE script –
Breaking down the commands listed in the sample script above –
iPXE Example Script (UEFI)
Sample iPXE script –
Breaking down the commands listed in the sample script above –
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 –
E.g. –
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.”
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 –
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 –
To check the path(s) in your BCD store (e.g. C:\pxesrv\files\boot\BCD), use the following bcdedit command –
Output from running the above command on the BCD store available here –
And the relevant section for the *.wim file (note the path is specified in the device and osdevice lines as \boot\boot.wim) –
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.
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 –
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…
…and entries for boot.wim and boot.sdi is used in the test below.
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.
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 –
Add the following to C:\pxesrv\files\pxelinux.cfg\default (create this file if required) –
Contents of C:\pxesrv\files\wimboot_lkrn.txt (create this file if required) –
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 –
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. –
Click on one of the following for sample config.ini settings (edit to reflect your own setup) –
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 –
Add the following to C:\pxesrv\files\menu.lst\default (create this file if required) –
Contents of C:\pxesrv\files\wimboot_lkrn.txt (create this file if required) –
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 –
Click on one of the following for config.ini settings (edit to reflect your own setup) –
iPXE settings
Remember to ensure that the required files are copied to your Tiny PXE Server root directory –
Add the following to the menu section of C:\pxesrv\files\ipxe_menu.txt (create this file if required) –
Add the following to the menu options section of C:\pxesrv\files\ipxe_menu.txt –
E.g. –
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) –
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 –
Sample iPXE script configured to load the correct boot file based on platform firmware –
Document date – 28th February 2017(DRAFT)
Поделиться:
By serg • iPXE, PXE, uefi 0