Impossible to boot on PXE......

[george1421]

We may need the eyes of @Sebastian-Roth to decode the pcap file. But the filter you should use in wireshark is " bootp || tftp". That should pick up the dhcp requests as well as the tftp download from the fog server.

[arnaudrigole]

FRESH NEWS!!! But also doesn’t work … ^^

In the client BIOS, i defined the NIC controller enabled on w/PXE and not w/PXE/ImageServer. Now, DHCP gives an IP to my computer, then it displays:

" iPXE itinialising devices … OK"
iPXE 1.0.0+ '3a02) – Open Source Network Boot firmware – http://ipxe.org
Features NFS FTP HTTP HTTPS iSCSI DNS TFTP VLAN AoE bzImage ELF MBOOT PXE PXEX
Menu
Configuring (net0 d0:67:xx:xx:xx:xx)

Then it displays some lines i couldn’t see because of the speed… and it reboot…

[george1421]

@arnaudrigole Well in a way that is great so you have dhcp working since its now getting the ipxe boot file!! Debugging with wireshark is not a fun way to spend the afternoon.

The bad part is we need that message that goes by too quick. From the bios settings you mentioned, are you deploying to a Dell computer? Either way what make and model are you trying to deploy to?

Something else, if you use your mobile phone and video record the booting process, you may have a chance to review the video/stop the video to see the error.

[arnaudrigole]

@george1421

Yeah, it’s true haha

I try to deploy on a DELL Optiplex 390. I want to upload its template system i installed to my fog server.

Good idea! but my camera is not good, i try!

[arnaudrigole]

@george1421
The message displayed is actually the rest of the line
“Configuring (net0 xx:xx:xx:xx …) and its :
" Error 0x040ee119 http://ipxe.org/040ee119”

i go on it

[george1421]

Good catch, you must have very fast eyes.

That error means that this computer either did not receive dhcp address from inside the ipxe kernel or the ipxe kernel could not configure the network adapter.

I use fog on 790s and it works OK. Is your 390 using the latest (or current) BIOS?

I might recommend (if you can tolerate a few little bugs) that you upgrade to the trunk version (i.e. soon to be 1.3.0 version) so that you have the latest drivers and programs for FOG. Since this is new to your company having a little instability to get the current files may be beneficial for this test.

Don’t get sad with FOG. FOG does work rather well, you just have a unique environment that we need to work (around). Here are the instructions for upgrading to the current trunk build https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk
This build will be updated almost daily as new fixes are released. If you find a bug, report it to the forum and it is usually addressed in one day.

[JJ Fullmer]

I would firstly strongly recommend upgrading to trunk. It includes the latest version of ipxe which alone could fix the issue.
But I have a few other ideas from my tests of difficult networks that I’ve gotten FOG working on.

So if I understand correctly you already have reserved ips on your windows dhcp for the hosts you are testing. Does FOG also have a reserved IP address in the dhcp? Something I’ve had good luck with is giving FOG a reservation on the DHCP server (On the same subnet as the computers it’s imaging, even if you have seperate subnets for servers and workstations) and a DNS entry too and then set option 66 with the FQDN (Fully Qualified Domain Name/Hostname.domain). This could be part of the issue here, but since you’re getting as far as you are it probably isn’t, but it could help since it may help the with getting the dhcp address.

So in summary of that idea

• Give FOG a dhcp reservation
• Give FOG a dns reservation
• Set Option 66 to hostname

Now A separate idea, even though you do have the dhcp method working. If it continues to give you grief you can give proxy dhcp via dnsmasq a try. I’ve had luck with it in environments that don’t like being edited. You typically don’t want to use poth the dhcp option and dnsmasq, however in some harder to modify network configurations, it is helpful to have both running. But I’ve also seen where one breaks the other, so just be aware of that when trying. So if you try this method, I would try unsetting option 66 and 67. And if it doesn’t work try setting the options again.

I put some information about configuring dnsmasq in a post in this thread
https://forums.fogproject.org/topic/6262/tftp-problems/43

There is also more information in the wiki
https://wiki.fogproject.org/wiki/index.php/ProxyDHCP_/dnsmasq-_DRAFT
https://wiki.fogproject.org/wiki/index.php/Using_FOG_with_an_unmodifiable_DHCP_server/Using_FOG_with_no_DHCP_server

Hopefully that’s helpful in some way.

[Sebastian Roth]

Interesting post! Great that you got it as far as iPXE being loaded from TFTP. iPXE itself does another round of DHCP to be able to communicate and load things like the kernel or menu via HTTP. You wonder why this is not working if DHCP does work on the first run before iPXE. Spanning tree settings on your switch might be an issue here. But quite often this would cause an issue earlier on already. But you can still try setting “port fast” on this switch port where your client is connected. Newer versions of iPXE are better at handling this. But not the one coming with FOG 1.2.0 AFAIK.

I really love diving into a PCAP dump as this is right down to the details. I don’t need to guess what’s going on. I just see it. I am more than happy to have a look if you upload a PCAP file! Wireshark filter bootp && tftp is great for this (or port 67 or port 68 or port 69 if you are using tcpdump)…

[arnaudrigole]

@Arrowhead-IT @Sebastian-Roth @george1421

Ok, il will upgrade to trunk to test

Thanks for ur help, i will try to set up the first solution and i come back to say you whats up
i’ll try to capture with wireshark before i do this modifications

Regards

[cschneider.tech]

@arnaudrigole said:

Hi,

Thanks for your fast response!!!

10.1.18.180 (fog server IP) is defined on option 66
undionly.kpxe is defined on option 67

The reason why those options are not defined directly is not simple…
Orange, our service provider for IP phones, used our DHCP options to load the AASTRA phones firmware by PXE, to simplify the configuration…
Then, these reboot on dedicated voice vlan… (F*CK)… so i’m forced to find a solution to skirt this… Precision : i havent used FOG as DHCP server, did i had to?

When i boot on NIC; thats steps are displayed:
1/ Initializing and establishing link…
2/ CLIENT MAC ADDR: XXXXXXXXXXX GUID XXXXXXXXXX
CLIENT IP : 10.1.19.233 MASK 255.255.0.0
GATEWAY X.X.X.X

3/ PXE-E32: TFTP open timeout
4/ PXE-M0F: Exiting Intel Boot Agent

Selected boot device failed, press any key to reboot…

Did this problem get solved? If so, how? I am having the EXACT same problem even after upgrading to build 6064

[arnaudrigole]

i’ll work on it tomorrow, i’ll come back with pcap file but i need to move my machines on a cisco manageable switch to setup the port mirroring, before setup the trunk to resolve (?) the problem.

I will give you the status here
Thanks for your precious help

Regards

[arnaudrigole]

@Sebastian-Roth

Hi !

I just registered two wireshark sessions, the first (OPX390.pcapng) is the one which have the problem i mentioned previously,

the second (E5410) is another one which try to contact the IP 10.1.18.180 while the FOG server IP is configured to 10.1.11.170 (i updated option 66 in DHCP)

Re-Edit: for the second problem, i think its about fog configuration, because i defined 10.1.18.180 while i installed fog. I modified the “FOG_WOL_HOST” to “10.1.11.170”, and “FOG_TFTP_HOST” , but the problem persists:
http://10.1.18.180/fog/service/ipxe/boot.php … connection reset (http://ipxe.org/0f0c6039) Could not boot: connection reset

Opx390:(3kb)
https://owncloud.lesrigole.fr/index.php/s/IPr0bf63jsRfkeV/download
E5410:(5mb???)
https://owncloud.lesrigole.fr/index.php/s/0oKDyDCtCaelCDu/download
Edit: Deleted because contains too much private informations…

@Arrowhead-IT @george1421
Now i’ll configure the trunk to try to resolve the problem

Thanks for your help!
Arnaud

[Sebastian Roth]

@arnaudrigole There is not much information in OPX390.pcapng. I see three DHCP discovery packets (probably from this machine) but nothing else related to DHCP or PXE booting. So this does not look like the boot process is being captured. As well I see “MSFT 5.0” being set as vendor class identifier in thos DHCP discovery packets. Is it windows asking for an IP address? Anyhow. This is not helpful, sorry.

[arnaudrigole]

@Sebastian-Roth

Thanks for your reply!

Ok, i used filters “tftp && bootp” however …? Which one i must use to do a better capture ?

MSFT 5.0 ? Strange… i just set up “MAC Adress” “is equal :” in my dhcp strategy as you can see:

Any idea for my second problem?
I re-ran the installfog.sh , defined IP to 10.1.11.170, IP of the storage node and i looked at all parameters on FOG interface > FOG Configuration > FOG Settings

And my PC still try to open http://10.1.18.180/fog/service/ipxe/boot.php… ?

[Wayne Workman]

@george1421 said:

But the filter you should use in wireshark is " bootp || tftp".

wiki

[Wayne Workman]

@arnaudrigole said:

And my PC still try to open http://10.1.18.180/fog/service/ipxe/boot.php… ?

Look for FOG Configuration -> FOG Settings -> Web Server -> FOG_WEB_HOST

[Wayne Workman]

Also, this might be a good time to introduce this: http://sourceforge.net/p/fogupdateip/code/HEAD/tree/

Works great on CentOS 7 and Fedora 23 Server.

It basically allows your FOG server to be assigned any IP from a pre-existing DHCP server, and it auto-configures the server and dnsmasq for you every time the ip changes.

[arnaudrigole]

@Wayne-Workman

Hi !
Thanks for your reply!
value in “FOG_WEB_HOST” is the true ip… no problem.

I’ll update to trunk today
does FogUpdateIP works on Debian 8 jessie?

[Sebastian Roth]

@arnaudrigole For your second issue take a look at /tftpboot/default.ipxe on your FOG server and edit as needed.

Thanks Wayne, I must have been half asleep when writing the post about wireshark filters. Sure it ought to be bootp || tftp (not &&)!! Can you please try again? Keep your wireshark ready, set with those filters, then bootup the client (cold boot!) and see if you get more packets.

[arnaudrigole]

@Sebastian-Roth

Ok, i go on it and i’ll post the reply fast