[ipxe-devel] iPXE, iscsi, isc-dhcp on FreeBSD 10.x

Michael Brown mcb30 at ipxe.org
Tue Mar 22 19:35:02 UTC 2016

On 22/03/16 18:03, pathiaki2 wrote:
> Now, I'm trying to PXEboot ye olde Dell Latitude 5500 laptop and I seem
> to be a wonderful circular loop.
>  <snip>
> CLIENT MAC ADDR:  00 23 AE 14 A8 50 GUID <blather>
> CLIENT IP: 192.168.021 MASK: DHCP IP:
> PXE->EB: !PXE at 9A22:0040, entry point at 9A22:00D6
>          UNDI code segment 9A22:4b50, data segment 966A:3B80
>          UNDI device is PCI 09:00.0, type DIX+802.3
>          601kB free base memory after PXE unload
> iPXE initialising devices...ok
> iPXE 1.0.0+ (c32b) -- Open Source Network Boot Firmware -- http://ipxe.org
> net0: 00:23:ae:14:a8:50 using undionly on UNDI-PCI09:00.0 (open)
>      [Link: up, TX:0 TXE:0 RX:0 RXE:0]
> Configuring (net0 00:23:ae:14:a8:50)...... ok
> net0: gw <--- Different Address???
> Nothing to boot:  No such file or directory (http://ipxe.org/2d03e13b)
> No more network devices
> Now, it seems it contacted the DHCP server a second time and got a
> different address?  Why?  (And how do I stop it from doing that?)

You haven't actually seen any circular loop in the above.  You have seen:

1. The Intel PXE ROM makes a DHCP request
2. The DHCP server instructs the Intel PXE ROM to download iPXE 
3. iPXE makes a DHCP request
4. The DHCP server gives iPXE nothing to boot
5. iPXE complains that it has nothing to boot, and exits

The problem in this configuration is that your DHCP server needs to give 
iPXE something to boot.  You can fix this by editing /etc/dhcpd.conf to 

     if exists user-class and option user-class = "iPXE" {
        filename "";
        option root-path 
     } else {
        filename "boot/undionly.kpxe";

Note that this is very similar to what you already have in your 
dhcpd.conf, except that:

a) yours is commented out, and so will do nothing
b) yours has the "if" and "else" parts the wrong way around

That should be enough to fix the problem.

> So, how do I keep the settings it has on the first load and keep it from
> contacting DHCP again?

Short answer: you don't.  Use the fix described above instead.

Much longer answer (for interest only):

You don't.  You really do want a second DHCP request to happen, because 
you want the two DHCP responses to contain different instructions.  The 
first DHCP response (to the Intel PXE ROM) will instruct it to download 
undionly.kpxe.  The second DHCP resposne (to iPXE) will instruct it to 
boot from the iSCSI target.

You can use an embedded script (http://ipxe.org/embed) to instruct iPXE 
to not issue a second DHCP request.  The embedded script might look 
something like:

   sanboot ${root-path}

That would cause iPXE to just reuse the DHCP settings obtained by the 
Intel PXE ROM.  However, those DHCP settings almost certainly would not 
contain the root-path or initiator-iqn, since the Intel PXE ROM would 
not have requested those settings.

The only downside of making a second DHCP request is that some DHCP 
server configurations will (as you have discovered) assign a different 
address for the second request, because they believe it to be coming 
from a different client.  This problem isn't specific to iPXE: you may 
also get a different address assigned once you boot into the OS.  You 
can work around this by explicitly using a short lease time for any PXE 

Hope that helps,


More information about the ipxe-devel mailing list