Impossible to boot on PXE......
-
@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
-
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. -
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/43There 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_serverHopefully that’s helpful in some way.
-
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 (orport 67 or port 68 or port 69
if you are using tcpdump)… -
@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 modificationsRegards
-
@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 67The 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.X3/ PXE-E32: TFTP open timeout
4/ PXE-M0F: Exiting Intel Boot AgentSelected 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
-
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 helpRegards
-
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 resetOpx390:(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 problemThanks for your help!
Arnaud -
@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.
-
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 SettingsAnd my PC still try to open http://10.1.18.180/fog/service/ipxe/boot.php… ?
-
-
@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
-
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.
-
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? -
@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. -
Ok, i go on it and i’ll post the reply fast
-
@Sebastian-Roth
Ok, after i’ve edited “default.ipxe” it works, my PC boot on pxe interface
i tried to upload the image of PCSo: I created a task to upload the current image from the PC to my FOG server, it begins, then it reboot after 1 minute without error message, i’ll post a pcap too.
Edit: Here is the pcap, protected by pw i’ll send you in private
https://owncloud.lesrigole.fr/index.php/s/m2EChdbHuTdo3fW/authenticateEDIT IMPORTANT: I defined the storage type in my image settings to “multiple partition image / not resizable” and it seems working; partclone is currently running on my computer.
For the first problem, here is the pcap file i recaptured with filter bootp || tftp
https://owncloud.lesrigole.fr/index.php/s/sq6LM3uo0OWzYwW/downloadReally appreciate your active help, from all you
-
@arnaudrigole said:
does FogUpdateIP works on Debian 8 jessie?
No, not yet anyway. I need to build a Debian server to mess around with.
-
@arnaudrigole As I already explained things usually should go like this: PC boots, NIC sends PXE DHCP discovery and gets back PXE information (next-server and filename). Then it loads the file via TFTP and executes it. FOG uses iPXE as a second stage. So far so good. From what I can see in the PCAP file this is perfectly happening for you. Cannot see any issues there. But then I see four DHCP requests from iPXE (which was loaded and executed as a first stage). But there is NO response from the DHCP server.
Either the DHCP server does not like the DHCP request (maybe some DHCP option that iPXE is sending) but I kind of doubt this as others seam to be able to use windows DHCP server without a problem.
Or it could be because of spanning tree (STP). The NIC is reset a couple of times while this PXE process is going on. If your switch has STP enabled but port fast is not used this might cause exactly the issue you see: https://wiki.fogproject.org/wiki/index.php/STP/Portfast/RSTP/FMSTP -
So it times out on the TFTP part? Change from undionly.kpxe to undionly.kkpxe