PXE-Boot into FOG-Menu....
A brief description of the network environment:
I use a DHCP server (Centos-based), which manages various VLAN. Included are two FOG servers (CentOS OS), a 1.2.0 and a 1.4.0 (running version 1.4.0
SVN revision: 6069). Both work mostly flawlessly. (WOL problems at 1.4.0 may be associated with the message “Pending macs” or the clients (Fujitsu Lifebook E554).
Now I have installed another FOG server (Ubuntu 16.04, because of chic) and set up, in the VLAN appropriately created (bootserver). Internet connection ok, ping to the computers works well, connected via patch cable to a workgroupswitch (cables are good). Hosts created, Image created, new computer (HP ProBook 650 G1) for image upload selected and set up in VLAN,
Booting via PXE is set up in the UEFI and works, IP is assigned, it remains hang with TFTP and the message PXE M0F: Exiting …
the next screen
“Network not found”
Before I install a new system (Centos) and try again from scratch, I politely ask for a solution.
Some things I’ve tried, including
service tftp … start
Using a dump switch
The thing with spinning tree etc. should not be the problem, as I use two other FOGs and these run fine within exactly this dhcp, though in another VLAN.
@Deimos Ok, great to hear this is fixed! I am marking this solved then. Feel free to open new threads in case you run into new issues.
Thanks to your great help, @Sebastian-Roth and @george1421, it has come out that the error was actually in our bootfile pxelinux, which was only linked to undionly.kpxe. On the FOG 1.4.4 I have also linked to undionly.kpxe and now everything works fine. The first image is also captured. Great! And again, thanks for your competent, helpful and friendly support.
I could not understand it - because of the existing and functioning FOG servers, which were set up by someone else - why the pxelinux.0 should no longer work, since it was evidently so arranged. But you professionals immediately realized that it would have to be a link. It was like this.
Follow up on this: The OP and I chatted over IM since the turn around to Q&A was much faster. After the OP reviewed the pcap file it was discovered that their dhcp server was sending out
pxelinuxas a boot file name. The OP was going to contact the network admin to try to understand why this was happening. I also pointed the OP to the wiki page: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence because the plan is to support both uefi and bios based computers on their network.
@george1421 The shaming is ok for me. We have several IP-Ranges (some important) and I just mask any of them just because of habit.
YES, they are on the same subnet.
Usually I like to collect more information, but I think we should jump right into a packet capture of the pxe booting process to tell us what is going on: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
If your fog server is on the same subnet as the target computer, use the fog server to collect this information so we can see the entire pxe booting process. If its on a different subnet then use wireshark with the same capture filter to capture the dhcp process. The wireshark computer needs to be on the same subnet as the target pxe booting computer.
You can either review with wireshark on ubuntu, or upload it to a google drive and share the link either here or send me an IM with the link and I will review it.
@deimos First the shaming… Its not helpful to mask the IP address of the device unless you have a public IP address range. There is no way for me to hack you if you are on 192.168.0.0 range externally.
Is your FOG server and this target server on the same subnet?
Sorry I didn´t write this, the new fog is 1.4.4.
Also please provide a clear screen shot of the error taken with a mobile phone. The context of the error will help us solve your issue.
Wayne Workman last edited by
@deimos Latest stable version is 1.4.4, try this please. There’s lots of fixes in every release.