(2017-01-15 10:13)NiKiZe Wrote:  I think there is one patch for ibft in efi mode on the mailing list that you want to grab, there is also one patch about executable boot.

Normaly winboot is used to boot into winpe, which has worked for quite some time...


http://lists.ipxe.org/pipermail/ipxe-devel/2016-December/005305.html
http://lists.ipxe.org/pipermail/ipxe-devel/2016-December/005291.html
http://lists.ipxe.org/pipermail/ipxe-devel/2016-December/005311.html

There is one or 2 other patches from Vishvananda Ishaya Abrams which you might want to apply, most of them from December.

(2017-01-16 23:22)scan80269 Wrote:  

(2017-01-15 10:13)NiKiZe Wrote:  I think there is one patch for ibft in efi mode on the mailing list that you want to grab, there is also one patch about executable boot.

Normaly winboot is used to boot into winpe, which has worked for quite some time...


http://lists.ipxe.org/pipermail/ipxe-devel/2016-December/005305.html
http://lists.ipxe.org/pipermail/ipxe-devel/2016-December/005291.html
http://lists.ipxe.org/pipermail/ipxe-devel/2016-December/005311.html

There is one or 2 other patches from Vishvananda Ishaya Abrams which you might want to apply, most of them from December.

Thanks for the pointers. Since I'm not a developer I don't think I'm up to the task of building iPXE with patches. I've been using rom-o-matic.eu to build snponly.efi. I suppose I can wait until rom-o-matic catches up to the various patches related to iBFT and executable boot.

(2017-02-13 04:42)ben Wrote:  it is has no iBFT table in UEFI Mode boot

(2017-04-24 11:35)dizUK Wrote:  Hi NikiZe, do you know if/when the iBFT patches are going to be merged?

(2017-04-24 15:05)mcb30 Wrote:  

(2017-04-24 11:35)dizUK Wrote:  Hi NikiZe, do you know if/when the iBFT patches are going to be merged?

All of the iBFT functionality for UEFI is now present in the master branch.

Michael

(2017-05-09 05:18)scan80269 Wrote:  Thanks for taking care of the iBFT for UEFI iPXE! I managed to get past the Win10 OS installation roadblock related to iBFT, and made it through the first OS installation phase. After the first reboot, I attempted to boot from the iSCSI disk, and got a 0x7f22208e error. I tried both ipxe.efi and snponly.efi with the same result. Not sure what is meant by "Platform-generated error".

(2017-01-15 07:06)scan80269 Wrote:  I'd like to express my appreciation for the implementation of EFI sanboot support in iPXE! Today I succeeded in getting a diskless client PC to EFI sanboot to WinPE, with a iSCSI virtual disk carrying GPT disk partitions.

I then initiated a Windows 10 (version 1607) OS installation into a mounted iSCSI virtual disk, but ran into the dreaded "iSCSI deployment is disabled since no NICs referenced in the iBFT can be resolved to actual NT-visible devices." error message. I'm trying to figure out what I might have done wrong, or whether iPXE may have an issue with iBFT in EFI mode.

(2018-11-02 23:03)scan80269 Wrote:  After a long hiatus I finally succeeded in booting Win10 version 1803 (RS4) in UEFI mode from an iSCSI disk via iPXE.

I switched to using wimboot for booting WinPE, and ROM-o-matic.eu came through with a snponly.efi that properly supports sanhook and sanboot of iSCSI GPT disks.

Along the way, I got messed up by some of the latest Intel NDIS65 drivers for the Intel Ethernet Connection I219-V. Apparently, the latest driver version that can support iSCSI boot is 12.15.25.6712 (dated Jul 12 2017). Any newer driver version induces the *STOP* Inaccessible Boot Device BSOD during Win10 bootup.

The only thing I noticed with UEFI iSCSI running is the virtual disk performance being lower than the legacy BIOS counterpart. Client disk-based Ethernet activity in/out of the server does not exceed 200Mbps most of the time.

(2019-01-26 05:56)scan80269 Wrote:  On my system acting as iSCSI disk server (running Windows Server 2012 R2/2016/2019 OS - with iSCSI Target Server feature enabled) I set up Tiny PXE Server to load ipxe-snponly-x86-64.efi (64-bit UEFI iPXE) for UEFI clients network booting via PXE. Once a client boots to iPXE, my iPXE script launches sanboot of an iSCSI virtual disk based on Ethernet MAC address match to initiate Win10 OS boot. The iSCSI virtual disk for the client is set up with GPT style disk partitions to properly support Win10 booting in UEFI mode (a Win10 requirement by Microsoft).

My iPXE script is set up such that sanboot of a virtual disk will fail if it doesn't have Win10 properly installed, in which case the script will continue onto launching wimboot to boot the client into WinPE in preparation for over-the-network Win10 OS installation into the iSCSI virtual disk dedicated to that client. I created a small (10GB) iSCSI virtual disk to carry the Win10 OS installation files, to avoid having to plug a USB flash drive into the client.

On many modern PCs, in order for UEFI PXE to work, "legacy" support (a.k.a. CSM - Compatibility Support Module) needs to be disabled in BIOS setup.

Once you can get a UEFI client to chain boot from PXE to iPXE, the rest, such as using sanboot to boot Win10 should be relatively straightforward.

(2019-01-26 17:24)psychrabi Wrote:  

(2019-01-26 05:56)scan80269 Wrote:  On my system acting as iSCSI disk server (running Windows Server 2012 R2/2016/2019 OS - with iSCSI Target Server feature enabled) I set up Tiny PXE Server to load ipxe-snponly-x86-64.efi (64-bit UEFI iPXE) for UEFI clients network booting via PXE. Once a client boots to iPXE, my iPXE script launches sanboot of an iSCSI virtual disk based on Ethernet MAC address match to initiate Win10 OS boot. The iSCSI virtual disk for the client is set up with GPT style disk partitions to properly support Win10 booting in UEFI mode (a Win10 requirement by Microsoft).

My iPXE script is set up such that sanboot of a virtual disk will fail if it doesn't have Win10 properly installed, in which case the script will continue onto launching wimboot to boot the client into WinPE in preparation for over-the-network Win10 OS installation into the iSCSI virtual disk dedicated to that client. I created a small (10GB) iSCSI virtual disk to carry the Win10 OS installation files, to avoid having to plug a USB flash drive into the client.

On many modern PCs, in order for UEFI PXE to work, "legacy" support (a.k.a. CSM - Compatibility Support Module) needs to be disabled in BIOS setup.

Once you can get a UEFI client to chain boot from PXE to iPXE, the rest, such as using sanboot to boot Win10 should be relatively straightforward.

If possible could you share the pxe script with me and the tiny pxe settings.
i want to try it once..

Also about the disabling the legacy support, does it mean we have to put the client to exclusive UEFI mode ?

(2019-01-26 18:30)scan80269 Wrote:  

(2019-01-26 17:24)psychrabi Wrote:  

(2019-01-26 05:56)scan80269 Wrote:  On my system acting as iSCSI disk server (running Windows Server 2012 R2/2016/2019 OS - with iSCSI Target Server feature enabled) I set up Tiny PXE Server to load ipxe-snponly-x86-64.efi (64-bit UEFI iPXE) for UEFI clients network booting via PXE. Once a client boots to iPXE, my iPXE script launches sanboot of an iSCSI virtual disk based on Ethernet MAC address match to initiate Win10 OS boot. The iSCSI virtual disk for the client is set up with GPT style disk partitions to properly support Win10 booting in UEFI mode (a Win10 requirement by Microsoft).

My iPXE script is set up such that sanboot of a virtual disk will fail if it doesn't have Win10 properly installed, in which case the script will continue onto launching wimboot to boot the client into WinPE in preparation for over-the-network Win10 OS installation into the iSCSI virtual disk dedicated to that client. I created a small (10GB) iSCSI virtual disk to carry the Win10 OS installation files, to avoid having to plug a USB flash drive into the client.

On many modern PCs, in order for UEFI PXE to work, "legacy" support (a.k.a. CSM - Compatibility Support Module) needs to be disabled in BIOS setup.

Once you can get a UEFI client to chain boot from PXE to iPXE, the rest, such as using sanboot to boot Win10 should be relatively straightforward.

If possible could you share the pxe script with me and the tiny pxe settings.
i want to try it once..

Also about the disabling the legacy support, does it mean we have to put the client to exclusive UEFI mode ?

It may depend on the client motherboard. Some systems like the Intel NUCs I use allow independent control of UEFI & legacy support, but whenever legacy support is enabled, the system will default to legacy PXE boot, so to get a NUC to do UEFI PXE boot, the legacy support option must be explicitly disabled. The PXE boot screens for UEFI and legacy typically look quite different, so it should be easy to tell which type of PXE boot the system is set to do.

Here's a sample iPXE script:

#!ipxe

#ifopen net0
#dhcp
set net0/gateway 0.0.0.0
echo IP: ${net0/ip}, Gateway: ${net0/gateway}
echo MAC address: ${mac}
set srvname iSCSIServer
set boot-url http://${next-server}
set keep-san 1
cpuid --ext 29 && set arch x64 || set arch x86
echo Platform type: ${platform}
echo Arch: ${arch}
echo ${platform}_${buildarch}
echo
prompt --timeout 5000 Press any key to continue ||
goto ${platform}_${buildarch} || goto unknown

:pcbios_x86_64
:efi_i386
echo This ${platform}_$(buildarch} PC is currently not supported!
goto exit

:pcbios_i386
iseq ${mac} b8:ae:ed:7d:8b:3f && sanboot iscsi:${next-server}::::iqn.1991-05.com.microsoft:${srvname}-win10rs4-6i5syh-target ||
iseq ${mac} 54:b2:03:15:03:8b && sanboot iscsi:${next-server}::::iqn.1991-05.com.microsoft:${srvname}-win10rs4-7i5dnhe-target ||
goto WinPEboot

:efi_x86_64
iseq ${mac} b8:ae:ed:7d:8b:3f && sanboot iscsi:${next-server}::::iqn.1991-05.com.microsoft:${srvname}-win10rs5-6i5syh-gpt-target ||
iseq ${mac} 54:b2:03:15:03:8b && sanboot iscsi:${next-server}::::iqn.1991-05.com.microsoft:${srvname}-win10rs5-7i5dnhe-gpt-target ||

:WinPEboot
# Mount OS install disk if all sanboot to OS attempts fail
sanhook --drive 0x81 iscsi:${next-server}::::iqn.1991-05.com.microsoft:${srvname}-win10rs5-install-target ||
echo
prompt Press any key to boot WinPE

# wimboot WinPE to prepare for OS installation
kernel ${boot-url}/wimboot gui
initrd -n segmono_boot.ttf ${boot-url}/Boot/fonts/segmono_boot.ttf segmono_boot.ttf ||
initrd -n segoe_slboot.ttf ${boot-url}/Boot/fonts/segoe_slboot.ttf segoe_slboot.ttf ||
initrd -n segoen_slboot.ttf ${boot-url}/Boot/fonts/segoen_slboot.ttf segoen_slboot.ttf ||
initrd -n wgl4_boot.ttf ${boot-url}/Boot/fonts/wgl4_boot.ttf wgl4_boot.ttf ||
iseq ${platform} pcbios && initrd -n bootmgr ${boot-url}/bootmgr bootmgr ||
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

:unknown
echo Unknown platform ${platform}_${buildarch}

:exit
Prompt Press a key to exit

Here's a sample config.ini for Tiny PXE Server:

[arch]
;will over rule the bootp filename or opt67 if the client arch matches one of the below
;00006=bootia32.efi
;00007=bootx64.efi
00007=ipxe-snponly-x86-64.efi
;00007=ipxe-x86_64.efi
;00009=bootx64.efi
[dhcp]
;needed to tell TFTPd where is the root folder
root=E:\pxesrv\files\
;bootp filename as in http://tools.ietf.org/html/rfc951
filename=ipxe-undionly.kpxe
;filename=ipxe-snponly-x86-64.efi
;alternative bootp filename if request comes from ipxe or gpxe
altfilename=BIOSnUEFI.ipxe
;start HTTPd
httpd=1
binl=0
start=0
dnsd=0
proxydhcp=1
;default=1
bind=1
;tftpd=1 by default
;will share (netbios) the root folder as PXE
smb=0
;will log to log.txt
log=0
;opt1=
;opt3=
;opt6=
;opt28=
;opt15=
;opt17=
;opt43=
;opt51=
;opt54=
;opt67=
;opt66=
;opt252=
poolstart=192.168.0.106
poolsize=0
;alternative bootp filename if request comes thru proxydhcp (udp:4011)
;proxybootfilename=
;any extra dhcp options
;my gpxe / ipxe dhcp options
optextra=175.6.1.1.1.8.1.1
;the below will be executed when clicking on the online button
;cmd=_test.bat
;if log=1, will log to log.txt
log=0
opt1=255.255.255.0
opt3=192.168.0.1
opt6=192.168.0.1
opt28=192.168.0.255
opt43=0
opt51=3600
opt54=192.168.0.105
next-server=192.168.0.105
opt60=PXEClient
opt66=192.168.0.105
opt17=
opt67=ipxe-undionly.kpxe
[frmDHCPServer]
top=10
left=968
[frmAbout]
top=486
left=509