efi_loader: add a README.iscsi describing booting via iSCSI
PATCH 1/1 efi_loader: add a README.iscsi describing booting via iSCSI
The appended README explains how U-Boot and iPXE can be used to boot a diskless system from an iSCSI SAN.
The maintainer for README.efi and README.iscsi is set.
--- MAINTAINERS | 2 + doc/README.iscsi | 178 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 180 insertions(+) create mode 100644 doc/README.iscsi
MAINTAINERS +2 -0
@@ -286,6 +286,8 @@ EFI PAYLOAD M: Alexander Graf <[email protected]> S: Maintained T: git git://github.com/agraf/u-boot.git +F: doc/README.efi +F: doc/README.iscsi F: include/efi* F: lib/efi*/ F: test/py/tests/test_efi*
doc/README.iscsi new file +178 -0
178 lines not on this page · raw message
Signature · 1 line
2.11.0
PATCH 1/1 efi_loader: add a README.iscsi describing booting via iSCSI
Quoted 31 lines · Heinrich Schuchardt
The appended README explains how U-Boot and iPXE can be used to boot a diskless system from an iSCSI SAN.
The maintainer for README.efi and README.iscsi is set.
Signed-off-by Heinrich Schuchardt <[email protected]>--- MAINTAINERS | 2 + doc/README.iscsi | 178 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 180 insertions(+)create mode 100644 doc/README.iscsi
MAINTAINERS +2
-0@@ -286,6 +286,8 @@ EFI PAYLOAD M: Alexander Graf <[email protected]> S: Maintained T: git git://github.com/agraf/u-boot.git +F: doc/README.efi +F: doc/README.iscsi F: include/efi* F: lib/efi*/ F: test/py/tests/test_efi*doc/README.iscsi new file +0
-0
doc/README.iscsi line 6
Quoted 6 lines
doc/README.iscsi new file +6
-0@@ -0,0 +1,178 @@ +# iSCSI booting with U-Boot and iPXE + +## Motivation + +U-Boot has only a reduced set of supported network protocols. A major gap is +the lack of a TCP stack.
This is only semi-true. There is work in progress to get TCP support into U-Boot. The protocols on top however are still missing and using iPXE here is definitely a very reasonable approach.
Quoted 39 lines
doc/README.iscsi new file +39
-0+ +For booting a diskless computer this leaves us with BOOTP or DHCP to get the +address of a boot script. TFTP can be used to load the boot script and the +operating system kernel and initial file system (initrd). + +These protocols are insecure. The client cannot validate the authenticity +of the contacted servers. And the server cannot verify the identity of the +client. + +Furthermore the services providing the operating system loader or kernel are +not the ones that the operating system will use. Especially in a SAN environment +this makes updating the operating system a hassle. After installing a new +kernel version the boot files have to be copied to the TFTP server directory. + +The HTTPS protocol provides certificate based validation of servers. Sensitive +data like passwords can be securely transmitted. + +The iSCSI protocol is used for connecting storage attached networks. It +provides mutual authentication using the CHAP protocol. It typically runs on +a TCP transport. + +Thus a better solution than DHCP/TFTP boot would be to load a boot script via +HTTPS and to download any other files needed for booting via iSCSI. + +An alternative to implementing these protocols in U-Boot is to use an existing +software that can run on top of U-Boot. iPXE is the "swiss army knife" of +network booting. It supports both HTTPS and iSCSI. It has a script engine for +fine grained control of the boot process and can provide a command shell. + +iPXE can be built as an EFI application (named snp.efi) which can be loaded and +run by U-Boot. + +## Boot sequence + +U-Boot loads the EFI application iPXE snp.efi using the bootefi command. This +application has network access via the simple network protocol offered by +U-Boot. + +iPXE executes its internal script. This script may optionally chain load a
doc/README.iscsi line 55
Quoted 10 lines
doc/README.iscsi new file +10
-0+secondary boot script via HTTPS or open a shell. + +For the further boot process iPXE connects to the iSCSI server. This includes +the mutual authentication using the CHAP protocol. After the authentication iPXE +has access to the iSCSI targets. + +For a selected iSCSI target iPXE sets up a handle with the block IO protocol. It +uses the ConnectController boot service of U-Boot to request U-Boot to connect a +file system driver. U-Boot reads from the iSCSI drive via the block IO protocol +offered by iPXE. It creates the partition handles and install the simple file
installs
doc/README.iscsi line 59
Quoted 4 lines
doc/README.iscsi new file +4
-0+protocol. Now iPXE can call the simple file protocol to load Grub. U-Boot uses +the block IO protocol offered by iPXE to fulfill the request. + +Once Grub is started it uses the same simple file protocol to load Linux. Via
Are you sure grub uses the file system protocol? IIRC it uses block directly.
Quoted 63 lines
doc/README.iscsi new file +63
-0+the EFI stub Linux is called as an EFI application. + +``` + +--------+ +--------+ + | | Runs | | + | U-Boot |=========>| iPXE | + | EFI | | snp.efi| ++--------+ | | DHCP | | +| |<====|********|<=========| | +| DHCP | | | Request | | +| Server | | | | | +| |====>|********|=========>| | ++--------+ | | Response | | + | | | | + | | | | ++--------+ | | HTTPS | | +| |<====|********|<=========| | +| HTTPS | | | Request | | +| Server | | | | | +| |====>|********|=========>| | ++--------+ | | Response | | + | | | | + | | | | ++--------+ | | iSCSI | | +| |<====|********|<=========| | +| iSCSI | | | Auth | | +| Server |====>|********|=========>| | +| | | | | | +| | | | Loads | | +| |<====|********|<=========| | +--------+ +| | | | Grub | | Runs | | +| |====>|********|=========>| |=======>| Grub | +| | | | | | | | +| | | | | | | | +| | | | | | Loads | | +| |<====|********|<=========|********|<=======| | +--------+ +| | | | | | Linux | | Runs | | +| |====>|********|=========>|********|=======>| |=====>| Linux | +| | | | | | | | | | ++--------+ +--------+ +--------+ +--------+ | | + | | + | | + | ~ ~ ~ ~| +``` + +## Security + +The iSCSI protocol is not encrypted. The traffic could be secured using IPsec +but iPXE does not support this. So we should at least separate the iSCSI traffic +from all other network traffic. This can be achieved using a virtual local area +network (VLAN). + +``` + +-----------+ + | | + | | + | iSCSI | + | Server | + | | + | | + +-----------+ + | + |iSCSI
doc/README.iscsi line 132
Quoted 10 lines
doc/README.iscsi new file +10
-0+ | ++-----------+ +-----------+ +-----------+ +| | VLAN 2 | * | | | +| |----------|****** | | | +| Diskless | | Managed | | Firewall | +| Computer | VLAN 1 | Switch | HTTP | | +| |==========|***********|==========|***********|=====$ +| | | | | | ++-----------+ +-----------+ +-----------+ +```
Is VLAN really in scope for this document? I guess it doesn't hurt, but it feels slightly out of place :)
Alex
Quoted 46 lines
doc/README.iscsi new file +46
-0+ +## Configuration + +### iPXE + +For running iPXE on arm64 the bin-arm64-efi/snp.efi build target is needed. + + git clone http://git.ipxe.org/ipxe.git + cd ipxe/src + make bin-arm64-efi/snp.efi -j6 EMBED=myscript.ipxe + +The available commands for the boot script are documented at: + +http://ipxe.org/cmd + +Credentials are managed as environment variables. These are described here: + +http://ipxe.org/cfg + +iPXE by default will put the CPU to rest when waiting for input. U-Boot does +not wake it up due to missing interrupt support. To avoid this behavior create +file src/config/local/nap.h. + + /* nap.h */ + #undef NAP_EFIX86 + #undef NAP_EFIARM + #define NAP_NULL + +The supported commands in iPXE are controlled by an include, too. Putting the +following into src/config/local/general.h is sufficient for most use cases. + + /* general.h */ + #define NSLOOKUP_CMD /* Name resolution command */ + #define PING_CMD /* Ping command */ + #define NTP_CMD /* NTP commands */ + #define VLAN_CMD /* VLAN commands */ + #define IMAGE_EFI /* EFI image support */ + #define DOWNLOAD_PROTO_HTTPS /* Secure Hypertext Transfer Protocol */ + #define DOWNLOAD_PROTO_FTP /* File Transfer Protocol */ + #define DOWNLOAD_PROTO_NFS /* Network File System Protocol */ + #define DOWNLOAD_PROTO_FILE /* Local file system access */ + +## Links + +* https://ipxe.org - iPXE open source boot firmware +* https://www.gnu.org/software/grub/ - GNU Grub (Grand Unified Bootloader)
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH 1/1 efi_loader: add a README.iscsi describing booting via iSCSI
Quoted 11 lines
----- Forwarded Message -----
From: Alexander Graf <[email protected]>
To: Heinrich Schuchardt <[email protected]>Quoted 7 lines
The appended README explains how U-Boot and iPXE can be used to boot a diskless system from an iSCSI SAN.
The maintainer for README.efi and README.iscsi is set.
Signed-off-by Heinrich Schuchardt <[email protected]>---
Quoted 7 lines
+U-Boot has only a reduced set of supported network protocols. A major gap is
Quoted 1 line
major gap is +the lack of a TCP stack.
This is only semi-true. There is work in progress to get TCP support into U-Boot. The protocols on top however are still missing and using iPXE here is definitely a very reasonable approach.
We are implementeinga limited TCP and a wget (http 1.0) app. It is almost ready for an test release. Selective Acknowledgment (SACK) is under test as a final piece of the TCP stack.
We have noticed that omitting the http 1.0 declaration in downloading the kernel from an nginx web server that we remove the overhead of an http header completely.
Quoted 6 lines
Quoted 6 lines
(quoted diff) +2
-0+ +For booting a diskless computer this leaves us with BOOTP or DHCPto get the +address of a boot script. TFTP can be used to load the boot script and the +operating system kernel and initial file system (initrd).
We use DHCP or DNS. DHCP assumes one has control of the DHCP server and are generally inside the firewall, and is complex to adminsited is there are many (branch office) DHCP servers. With MS 2012 R2 server configuring DHCP options is complex.
Quoted 3 lines
Quoted 3 lines
+These protocols are insecure. The client cannot validate the authenticity +of the contacted servers. And the server cannot verify the identity of the +client.
Yes and no. We (optionally) use the burnt in MAC address or serial number to identify a client machine, and can prevent boot if it is not authorized by denying the download of the *nix kernel. If inside the firewall and using DHCP security is probably completly under the control of the enterprise admins. We use locally administered DNS servers to control address resolution under DNS.
Quoted 4 lines
Quoted 4 lines
iPXE is the
"swiss army knife" of +network booting. It supports both HTTPS and iSCSI. It has a script engine for +fine grained control of the boot process and can provide a command shell. +
(1)u-boot (+ missing functions)->iPXE->grub->kernel (appears complex) or
(2)u-boot (+ missing functions)->kernel?
Quoted 1 line
Quoted 1 line
+protocol. Now iPXE can call the simple file protocol to load Grub.
I seem to be missing the point. We use U-boot to load and run the kernel with tcp+http 1.0. https would be a nice enhancement, as would an encrypted connection for the *nix kernel to access the image, but complete security requires more.
If you are going to do this we need to discuss accessing the *nix image over a secure protocol. AFAIK the *nix kernel does not use secure protocols with network *nix images.
In the netboot process we'd address the performance limitations of NFS, especially during boot, with either lookahead caching at the client or use HTTPS for image access, both of which are outside u-boot's scope.
PATCH 1/1 efi_loader: add a README.iscsi describing booting via iSCSI
Quoted 39 lines · Duncan Hare
Quoted 11 lines
----- Forwarded Message -----
From: Alexander Graf <[email protected]>
To: Heinrich Schuchardt <[email protected]>Quoted 7 lines
The appended README explains how U-Boot and iPXE can be used to boot a diskless system from an iSCSI SAN.
The maintainer for README.efi and README.iscsi is set.
Signed-off-by Heinrich Schuchardt <[email protected]>---
Quoted 7 lines
+U-Boot has only a reduced set of supported network protocols. A major gap is
Quoted 1 line
major gap is +the lack of a TCP stack.
This is only semi-true. There is work in progress to get TCP support into U-Boot. The protocols on top however are still missing and using iPXE here is definitely a very reasonable approach.
We are implementeinga limited TCP and a wget (http 1.0) app. It is almost ready for an test release. Selective Acknowledgment (SACK) is under test as a final piece of the TCP stack.
We have noticed that omitting the http 1.0 declaration in downloading the kernel from an nginx web server that we remove the overhead of an http header completely.
Quoted 6 lines
Quoted 6 lines
(quoted diff) +2
-0+ +For booting a diskless computer this leaves us with BOOTP or DHCPto get the +address of a boot script. TFTP can be used to load the boot script and the +operating system kernel and initial file system (initrd).
We use DHCP or DNS. DHCP assumes one has control of the DHCP server and are generally inside the firewall, and is complex to adminsited is there are many (branch office) DHCP servers. With MS 2012 R2 server configuring DHCP options is complex.
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
+These protocols are insecure. The client cannot validate the authenticity +of the contacted servers. And the server cannot verify the identity of the +client.
Yes and no. We (optionally) use the burnt in MAC address or serial number to identify a client machine, and can prevent boot if it is not authorized by denying the download of the *nix kernel.
A MAC adress can easily be spoofed. So an unauthorized system can download the initram file system to obtain secret data like /etc/shadow.
Without DNSsec the client cannot be sure to whom he is talking.
If inside
Quoted 13 lines
the firewall and using DHCP security is probably completly under the control of the enterprise admins. We use locally administered DNS servers to control address resolution under DNS.
Quoted 4 lines
Quoted 4 lines
iPXE is the
"swiss army knife" of +network booting. It supports both HTTPS and iSCSI. It has a script engine for +fine grained control of the boot process and can provide a command shell. +(1)u-boot (+ missing functions)->iPXE->grub->kernel (appears complex) or
(2)u-boot (+ missing functions)->kernel?
Quoted 6 lines
Quoted 1 line
Quoted 1 line
+protocol. Now iPXE can call the simple file protocol to load Grub.
I seem to be missing the point. We use U-boot to load and run the kernel with tcp+http 1.0. https would be a nice enhancement, as would an encrypted connection for the *nix kernel to access the image, but complete security requires more.
With http the client cannot find out from where he is downloading.
iPXE offers to install an SSL certificate to verify that it is talking to the right https server and can send user and password over the secure channel so the server can verify that the client is authorized for the requested resource. With iSCSI there is only the CHAP protocol for mutual authentication.
For SSL you need good random numbers. For U-Boot the only viable source of randomness is the network or a random seed updated by the operating system. Some SOCs additionally offer an internal source of randomness.
Quoted 4 lines
If you are going to do this we need to discuss accessing the *nix image over a secure protocol. AFAIK the *nix kernel does not use secure protocols with network *nix images.
Once you have loaded the image and initrd over a secure channel like https or ipsec the kernel can connect to a network drive using ipsec.
Quoted 5 lines
In the netboot process we'd address the performance limitations of NFS, especially during boot, with either lookahead caching at the client or use HTTPS for image access, both of which are outside u-boot's scope.
The limiting factors for all network protocols are the ping time for IOps and the bandwidth for download speed. Only NVMe over TCP will bring a real improvement for IOps.
Some small TCP stacks can only have one request in flight at the same time which is further limiting.
With iPXE I have been downloading the kernel and intird at over 30 MB/s which means less than 2 seconds out of 25 seconds for the full reboot on an Odroid C2.
PATCH 1/1 efi_loader: add a README.iscsi describing booting via iSCSI
In reply to Duncan HareQuoted 15 lines · Duncan Hare
Quoted 15 lines
----- Forwarded Message -----
From: Alexander Graf <[email protected]>
To: Heinrich Schuchardt <[email protected]>Quoted 7 lines
The appended README explains how U-Boot and iPXE can be used to boot a diskless system from an iSCSI SAN.
The maintainer for README.efi and README.iscsi is set.
Signed-off-by Heinrich Schuchardt <[email protected]>---
+U-Boot has only a reduced set of supported network protocols. A major gap is
Quoted 1 line
major gap is +the lack of a TCP stack.
Quoted 7 lines
Quoted 3 lines
This is only semi-true. There is work in progress to get TCP support into U-Boot. The protocols on top however are still missing and using iPXE here is definitely a very reasonable approach.
We are implementing a limited TCP and a wget (http 1.0) app. It is almost ready for an test release. Selective Acknowledgment (SACK) is under test as a final piece of the TCP stack.
In which git can I find the code?
Quoted 5 lines
We have noticed that omitting the http 1.0 declaration in downloading the kernel from an nginx web server that we remove the overhead of an http header completely.
I would prefer if the implementation were compliant with either of RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 or RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0
You should not program to please another accommodating software but according to a standard.
The key to TCP performance is supporting multiple packets in flight.
Best regards
Heinrich
PATCH 1/1 efi_loader: add a README.iscsi describing booting via iSCSI
In reply to Alexander GrafQuoted 36 lines · Alexander Graf
Quoted 35 lines · Heinrich Schuchardt
The appended README explains how U-Boot and iPXE can be used to boot a diskless system from an iSCSI SAN.
The maintainer for README.efi and README.iscsi is set.
Signed-off-by Heinrich Schuchardt <[email protected]>---
MAINTAINERS | 2 +
doc/README.iscsi | 178
+++++++++++++++++++++++++++++++++++++++++++++++++++++++2 files changed, 180 insertions(+)create mode 100644 doc/README.iscsi
MAINTAINERS +0
-0@@ -286,6 +286,8 @@ EFI PAYLOADM: Alexander Graf <[email protected]>
S: Maintained
T: gitgit://github.com/agraf/u-boot.gitMAINTAINERS +2
-0+F: doc/README.efi +F: doc/README.iscsiF:
include/efi*
F:lib/efi*/
F: test/py/tests/test_efi*doc/README.iscsi new file +3
-0@@ -0,0 +1,178 @@ +# iSCSI booting with U-Boot and iPXE + +## Motivation
Quoted 9 lines
Quoted 4 lines
doc/README.iscsi new file +2
-0+ +U-Boot has only a reduced set of supported network protocols. A majorgap is
+the lack of a TCP stack.This is only semi-true. There is work in progress to get TCP support into U-Boot. The protocols on top however are still missing and using iPXE here is definitely a very reasonable approach.
I can mention that this is work in progress.
Quoted 168 lines
Quoted 67 lines
doc/README.iscsi new file +2
-0+ +For booting a diskless computer this leaves us with BOOTP or DHCP toget the
+address of a boot script. TFTP can be used to load the boot script and thedoc/README.iscsi new file +3
-0+operating system kernel and initial file system (initrd). + +These protocols are insecure. The client cannot validate theauthenticity
+of the contacted servers. And the server cannot verify the identity of thedoc/README.iscsi new file +3
-0+client. + +Furthermore the services providing the operating system loader orkernel are
+not the ones that the operating system will use. Especially in a SAN environment
+this makes updating the operating system a hassle. After installing a new
+kernel version the boot files have to be copied to the TFTP server directory.doc/README.iscsi new file +2
-0+ +The HTTPS protocol provides certificate based validation of servers.Sensitive
doc/README.iscsi new file +4
-0+data like passwords can be securely transmitted. + +The iSCSI protocol is used for connecting storage attached networks. It +provides mutual authentication using the CHAP protocol. It typicallyruns on
doc/README.iscsi new file +3
-0+a TCP transport. + +Thus a better solution than DHCP/TFTP boot would be to load a bootscript via
doc/README.iscsi new file +3
-0+HTTPS and to download any other files needed for booting via iSCSI. + +An alternative to implementing these protocols in U-Boot is to use anexisting
+software that can run on top of U-Boot. iPXE is the "swiss army knife" of
+network booting. It supports both HTTPS and iSCSI. It has a script engine for
+fine grained control of the boot process and can provide a command shell.doc/README.iscsi new file +2
-0+ +iPXE can be built as an EFI application (named snp.efi) which can beloaded and
doc/README.iscsi new file +5
-0+run by U-Boot. + +## Boot sequence + +U-Boot loads the EFI application iPXE snp.efi using the booteficommand. This
+application has network access via the simple network protocol offered bydoc/README.iscsi new file +3
-0+U-Boot. + +iPXE executes its internal script. This script may optionally chainload a
doc/README.iscsi new file +3
-0+secondary boot script via HTTPS or open a shell. + +For the further boot process iPXE connects to the iSCSI server. Thisincludes
+the mutual authentication using the CHAP protocol. After the authentication iPXEdoc/README.iscsi new file +3
-0+has access to the iSCSI targets. + +For a selected iSCSI target iPXE sets up a handle with the block IOQuoted 7 lines
protocol. It
+uses the ConnectController boot service of U-Boot to request U-Boot to connect a
+file system driver. U-Boot reads from the iSCSI drive via the block IO protocol
+offered by iPXE. It creates the partition handles and install the simple fileinstalls
Quoted 6 lines
+protocol. Now iPXE can call the simple file protocol to load Grub. U-Boot uses
doc/README.iscsi new file +3
-0+the block IO protocol offered by iPXE to fulfill the request. + +Once Grub is started it uses the same simple file protocol to loadLinux. Via
Are you sure grub uses the file system protocol? IIRC it uses block directly.
Quoted 79 lines
doc/README.iscsi new file +38
-0+the EFI stub Linux is called as an EFI application. + +``` + +--------+ +--------+ + | | Runs | | + | U-Boot |=========>| iPXE | + | EFI | | snp.efi| ++--------+ | | DHCP | | +| |<====|********|<=========| | +| DHCP | | | Request | | +| Server | | | | | +| |====>|********|=========>| | ++--------+ | | Response | | + | | | | + | | | | ++--------+ | | HTTPS | | +| |<====|********|<=========| | +| HTTPS | | | Request | | +| Server | | | | | +| |====>|********|=========>| | ++--------+ | | Response | | + | | | | + | | | | ++--------+ | | iSCSI | | +| |<====|********|<=========| | +| iSCSI | | | Auth | | +| Server |====>|********|=========>| | +| | | | | | +| | | | Loads | | +| |<====|********|<=========| | +--------+ +| | | | Grub | | Runs | | +| |====>|********|=========>| |=======>| Grub | +| | | | | | | | +| | | | | | | | +| | | | | | Loads | | +| |<====|********|<=========|********|<=======| | +--------+ +| | | | | | Linux | | Runs| | +| |====>|********|=========>|********|=======>| |=====>| Linux | +| | | | | | | | | |++--------+ +--------+ +--------+ +--------+ | |
+
| |
+
| |
+
| ~ ~ ~ ~|
+```doc/README.iscsi new file +4
-0+ +## Security + +The iSCSI protocol is not encrypted. The traffic could be securedusing IPsec
+but iPXE does not support this. So we should at least separate the iSCSI traffic
+from all other network traffic. This can be achieved using a virtual local areadoc/README.iscsi new file +18
-0+network (VLAN). + +``` + +-----------+ + | | + | | + | iSCSI | + | Server | + | | + | | + +-----------+ + | + |iSCSI + | ++-----------+ +-----------+ +-----------+ +| | VLAN 2 | * | | | +| |----------|****** | | | +| Diskless | | Managed | | Firewall |
Quoted 8 lines
Quoted 5 lines
+| Computer | VLAN 1 | Switch | HTTP | | +| |==========|***********|==========|***********|=====$ +| | | | | |++-----------+ +-----------+ +-----------+ +```
Is VLAN really in scope for this document? I guess it doesn't hurt, but it feels slightly out of place :)
The security of iSCSI is worth mentioning but I can remove the drawing.
Quoted 61 lines
Alex
Quoted 54 lines
doc/README.iscsi new file +6
-0+ +## Configuration + +### iPXE + +For running iPXE on arm64 the bin-arm64-efi/snp.efi build target isneeded.
doc/README.iscsi new file +10
-0+ + git clone http://git.ipxe.org/ipxe.git + cd ipxe/src + make bin-arm64-efi/snp.efi -j6 EMBED=myscript.ipxe + +The available commands for the boot script are documented at: + +http://ipxe.org/cmd + +Credentials are managed as environment variables. These are describedhere:
doc/README.iscsi new file +4
-0+ +http://ipxe.org/cfg + +iPXE by default will put the CPU to rest when waiting for input.U-Boot does
+not wake it up due to missing interrupt support. To avoid this behavior createdoc/README.iscsi new file +8
-0+file src/config/local/nap.h. + + /* nap.h */ + #undef NAP_EFIX86 + #undef NAP_EFIARM + #define NAP_NULL + +The supported commands in iPXE are controlled by an include, too.Putting the
+following intosrc/config/local/general.his sufficient for most use cases.
+
+ /*general.h*/
+ #define NSLOOKUP_CMD /* Name resolution command */ + #define PING_CMD /* Ping command */
+ #define NTP_CMD /* NTP commands */
+ #define VLAN_CMD /* VLAN commands */
+ #define IMAGE_EFI /* EFI image support */ + #define DOWNLOAD_PROTO_HTTPS /* Secure Hypertext Transfer Protocol */
+ #define DOWNLOAD_PROTO_FTP /* File Transfer Protocol */ + #define DOWNLOAD_PROTO_NFS /* Network File System Protocol */ + #define DOWNLOAD_PROTO_FILE /* Local file system access */doc/README.iscsi new file +5
-0+ +## Links + +* https://ipxe.org - iPXE open source boot firmware +* https://www.gnu.org/software/grub/ - GNU Grub (Grand UnifiedBootloader)