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

[pathiaki2]

>> CLIENT MAC ADDR:  00 23 AE 14 A8 50 GUID <blather>
>> CLIENT IP: 192.168.021 MASK: 255.255.255.0 DHCP IP: 192.168.0.1
>> GATEWAY IP: 192.168.0.1
>> 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
>> Features:  DNS HTTP iSCSI TFTP AoE ELF MBOOT PXE bzImage Menu PXEXT
>>
>> 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:  192.168.0.159/255.255.255.0 gw 192.168.0.1 <--- 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 
> (undionly.kpxe)
> 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 contain
>
>     if exists user-class and option user-class = "iPXE" {
>        filename "";
>        option root-path 
> "iscsi:192.168.0.1::::iqn.2012-06.net.test:target0";
>     } 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:
>
>   #!ipxe
>   ifopen
>   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 clients.
>
Michael,

Here's for future reference......

When the machine gets its info wiped out, and the domain changes by one 
character.... go find the 'other' dhcp server that you forgot about is 
shut it down.  (*smacks his head*)  Yes, everything works just fine 
according to the documentation and everything else.  I'm working on a 
new issue and I'll post the resolution to all of this and the indication 
of the 'other' server  (mainly, the domain changing was the big one)

P.