Impossible to boot on PXE......
-
This post is deleted! -
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…
-
So far, everything looks good. I wanted to make sure you were using the IP address of the fog server and the right boot file name.
I understand about Orange (silly name change in my opinion), we used them about 10 years ago for WAN management.
Using the fog dhcp server is not mandatory and should be a second choice unless you don’t have a functioning dhcp environment.
The error message is for sure saying that it can’t reach either the fog server or the download file.
-
To this point we need to first find out if it is a dhcp issue or a FOG server issue. If you can, if you have a functioning windows server on the same subnet as the target computer. You may have to add the tftp client to your windows build, but try to tftp the file from the fog computer to your workstation. I’m only interested if you can or can’t download the undionly.kpxe from the fog server.
If you can access this file, then we need to understand why dhcp is not working as expected. If the target can load the undionly.kpxe file you should see the FOG ipxe menu.
-
I hope i understand as well as you want to.
I think its a DHCP issue too, because i’ve tested FOG in my home network and it works (load the kpxe, but kernel error, in short…)“You may have to add the ftdp client to your windows build” ?
You talk about windows dhcp server ? how to do this?In my home network, i havent did anything about this, i just installed fog, defined DHCP options 66 & 67 on a wsrvr 2012r2 (same in this case), and my client was directly able to boot on kpxe
-
Sorry my fingers got crossed when I typed a few words in the last post.
What I want you to do is this. On a working windows computer that is attached to the same subnet (vlan) where you want to deploy the fog image too… On that functioning Windows computer I want you to install a MS Windows tftp client. You do this through the add features and functions. Once this software is installed I want you to open a command window on that working computer and attempt to pull the undionly.kpxe from your fog server. To do this open a command window (once tftp client is installed) and key in:
tftp 10.1.18.180 GET undionly.kpxe .
The file is not important, I want to know if the file transfer is success. If you can get the file no problem then we will have to dig into dhcp. But one step at a time.
-
Thanks for your help,
I added the functionnality on my computer, the command worked and returned:
Transfert réussi : 103273 octets en 1 seconde(s), 103273 octets/s
-
@arnaudrigole Well this is good and bad news.
Good: Your FOG server is supplying the required files.
Bad: Now the issue is down to dhcp.The error message doesn’t mean that it is getting the wrong boot code (like for the phones), the error message says it is getting no boot code.
-
I think for the next part we will need to get a pcap file of what the target computer is communicating. This is a complex step that will require you to setup wireshark on a mirrored switch port and capture the packets as the target computer is requesting dhcp information from your dhcp server.
Before you go to this step, you may want to review your dhcp configuration to ensure you have the reservation setup correctly.
-
@george1421
I understand, i’ve already done port mirroring, i can do this but which filters did i setup on wireshark?I think my DHCP parameters are good, but how to know if the basic config (which define the PXE boot on IP phone server) override the strategy i defined??
-
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.
-
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…
-
@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.
-
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!
-
@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