@Base2Nathan Good to hear you figured it out. You might wonder why the config George suggested doesn’t use option tftp-server-... and option bootfile-name at all. There are two places in DHCP packets where PXE boot information can be placed. One is DHCP options as you have used them. But there is also next-server and filename what are fields within the DHCP header information. Take a closer look at the wireshark dump…

@Sebastian-Roth I did it and it’s work ! thanks a lot for your reply ans the time you spent for me 🙂

@george1421
New revelations have been made. As I said I now replicated the whole setup on a local isolated network (with exception of the apparmor modifications, not necessary on a bare-metal installation).

I have my witness-computer connected to both networks with 2 seperate NICs. Only one is active at a time. In both setups I first started wireshark on the witness computer and booted a notebook into pxe.

Main network: No packets or barely some DHCP-ACKs (that were not from the booting laptop). Isolated local network: Discover -> Offer -> Request -> ACK. Laptop got an IP from the router and loaded the appropriate bootrom from the fogserver and booted from it.

Conclusion: Since the witnessing of the DHCP-packets have nothing to do with fog itself it is safe to say that there is some sort of broadcoastfiltering of the DHCP-relevant ports. The (almost) exact same installation worked in an isolated network but not on the main network.

Thank you so much, I finally know the exact cause of the problem and am able to proceed. I now have to write up a request if the networking team would be so kind to allow the broadcoasting of those port-packets to a single static IP that I own (I really hope they’ll allow that. Now that I think of it this makes total sense. If people are able to plug in their own devices into the network that behave like a DHCP-Server and then handle the IPs before the main DHCP does you are in a golden MITM-position and can intercept with the network-packets to your desire). But as far as fog goes, this is nothing from its side.

So I think I can say this is solved for the cause of “troubleshooting”. Even if my journey is not exactly at its end yet. Thanks again!

@vijaybomble OK great you have the prerequsites in the proper configuration.

If your fog server is your dhcp server, and your pxe booting client are on the same subnet, lets use your fog server to capture what is pxe booting is doing on your network. You can use tcpdump on the fog server to capture only the traffic we need. I have a tutorial here on what you have to do: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Upload the pcap to this forum or use a private google drive and im me the link and I’ll take a look to see what is going wrong.

@BiologyBen It sounds like pxe booting was only the beginning of your challenge. Good luck!!

If you find new difficulties, please post to new thread and we will help you get started again.

@alwos Two comments.

Please open your own thread because your problem may not be the same. If you are more happy, use your native language to explain the problem because your post is not understandable.

Well… This is embarrassing.

Good news I fixed it, i get into the PXE menu now! 😄

I do have a different question now, when I click boot from hard disk in the pxe menu it doesn’t load the operating system, any ideas for that?

For the issue relating to TFTP this is what happened:

I set up a packet scan on both the DHCP and PXE server and after analyzing the packets i noticed there were two different packets sending a different option 66 and option 67. One was right pointing to the FOG server and Undionly.kpxe the other however pointed to the DHCP server. Apparently an old image deployment software was still working even though the options weren’t configure anymore. I removed these and everything worked great!

@melvinpaz Ok, this is a Mac client you are having problems with. Please tell us exactly which Mac you have (serial number!). The modifications you made are correct as far as I see.

I am wondering why it is saying “Could not open net1”. Are there two network cards in this client. Possibly wireless? Although I am pretty sure iPXE does not provide any wireless drivers. We need more information on the hardware (exact Mac model / serial number) to be able to help you.

Bonjour @Sebastian-Roth

Mon problème était bien la version du kernel mais pour mettre à jour le kernel il fallait que je rentre le proxy donc oui tu avais raison.

Maintenant j’ai un nouveau problème voici le message d’erreur

---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

############
Hello @Sebastian-Roth

My problem was indeed the version of the kernel but to update the kernel I had returned the proxy so yes you were right.

Now I have a new problem here is the error message

---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

@Wayne-Workman i wasn’t really clever in browsing this forum with my phone, so I thought hey Google may just pop with the answer quicker but I will certainly use that link for my reference for future mishap.

Thanks bud (Y)

I was able to confirm the issue of the sub directories not being created and after making the proposed suggestions the installer did indeed create the pxelinux.cfg and i386-efi folders. This issue was present on both Ubuntu and Fedora.

I’m marking this as solved.

@stan6595 Thank you for following up!

If you have any other problems, never hesitate to start a new thread! (search for a solution first though)

🙂

Solved.
Reason: windows 2012 dhcp failover error. (Two dhcp server with load balancing. Synhronization was’nt perfect, fog settings exist just one of them.) Sorry my english.