@smoooo If you are going to use two network adapters (recommended) before you install fog, know the linux name of the nic that will be your imaging network interface. Make sure you have static IP address mapping done on the imaging network interface. When you install FOG it will ask you which interface do you want to use. Make sure you name it correctly. Also FOG gets angry if you change the IP address of the imaging network interface after FOG is installed. So have your network configuration complete before you install FOG.

set the IP adress of the fog serveur
instead of the name “fogserver” at the install of the smartinstaller and enjoy 😄

I may have read your post too quickly, so if after you confirm the settings according to the wiki page, you still have issues we can debug using a packet capture. If the fog server and the pxe booting computer is on the same subnet, please use this tutorial to capture the best quality pcap. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

The pcap will show us what the target computer is being told to do.

If your pxe booting compute is on a different subnet then install wireshark on a witness computer (second computer not part of the pxe booting process). Use the wireshark capture filter of port 67 or port 68 to only capture the pxe boot.

Post the pcap to a file share site (like google drive) and either post the link in the thread or IM me the link and I will take a look at what the client is being told.

Thank you!

I clicked the update button but didnt wait long enough it seems.

Sorry for bothering you with this trivial stuff, thanks for the help.

Sébastien

@Richard-Wise Ah ok, then set this value in the web ui FOG Configuration->FOG Settings->(Expand all)->FOG Boot Settings->PXE MENU TIMEOUT change the value to 0

More info - from old fog I exported only hosts via web browser - old hosts when reinstalling have correct hash and snapins works smoothly. Issue is only with machines which I register.
No errors in fogsnapinhash.log

@tesparza If unicasts are fine, but multicasts are not then I would start with the igmp snooping. There may be another command that needs to be enabled for the catalyst line. I seem to remember there is but can’t remember the details at the moment.

@george1421 So actually we testet the ipxe.efi boot file and it Resolved the Error that we had. So thanks for the Help and Support, i hope it will stay so 🙂

@mmoore5553 Not a clue since I don’t have one to test with, sorry.

I don’t have an answer for you directly, but I can tell you how FOG work and how to reverse engineer a few things.

When a computer pxe boots it downloads the iPXE boot loader that has been customized by the FOG Developers. This will be ipxe.efi or undionly.kpxe (typically). Inside that boot loader the FOG Developers placed an initial iPXE script. That script calls a script on the FOG server called default.ipxe. That script then chains into FOG via the boot.php code. If you were to write your own code for the default.ipxe file (its just a text file) that displayed some background image and that had a count down timer. If no key is pressed then it would just boot from the hard drive. If a key was pressed then you could chain to the default FOG iPXE menu by calling the boot.php file directly.

So you will want to review the file /tftpboot/default.ipxe just know when you update fog it will overwrite this file so keep a backup if you alter it.

The next bit of hackery is seeing the text behind the FOG iPXE menu (I would use this as the framework for your own custom default.ipxe file). If you go to a web browser and key in http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00 that will display the text behind the FOG iPXE menu. In there its really a program that runs based on the iPXE programming language. You will see how menu entries work as well as the default menu selection as well as how the backgound image is called (hint you don’t have to use the fog background image for your custom boot menu).

Folks, thank you all so much for the advice here. And patience along with it too.

I got this working. Luckily enough, with the last image, the golden PC/VM did see internet, but all behaved perfectly.

Very minimal autounattend.xml manually edited to knock out a few options, FOG domain join worked super.

Again though very big thanks for nursing me through this one. It’s all working as it should and I’m extremely happy. 🙂

@sloeckle Well I can tell you that FOG doesn’t change any settings in the uefi menu, so that windows entry is probably from a previous install on that computer.

Now to your question about post download scripts. I have a tutorial that can be the starting point of your task.

The starting point could be here: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

If you start looking in this section of the post fog.custominstall

In the code you will see that I key off the $osdi field. In this case I check to see if its one of the windows platforms. In your case you can use the same overall code flow/outline but switch case the linux code of 50. If you look a bit deeper into what is going on in the windows section we loop through the different disk partitions on the disk looking for the /Windows directory on the partition. If its found then we exit the loop with the proper partition number.

In your case you will loop through the partitions looking for /EFI or /efi If you find that directory (you could even be a bit more specific like /efi/boot then you know what partition number the efi partition is. Yo u could also look at the partitions by the partition type but that could be a bit misleading because not every uefi partition is of type efi. Searching for the boot file path may be a bit more universal. For uefi the path don’t change. You just need to be mindful of the case.

Once you have the identified partition then you can do the magic with the efibootmgr. You could be blindfully trusting and just replace the value in boot order 0000 or do a bit more coding to identify the values you don’t want to purge, or just insert your linux boot manager always at position 0 and set it to default. That will push all of the other entries down one position. I think that may be a messy approach especially if you reimage that target computer a number of times, but it would get the job done.

@andydrew23 said in Fresh Install - PXE Fails:

Yeah, I’m handicapped. Thank you George

@jjacobs So now what is your end configuration you want? 1 server and 1 storage node at each location?

I’m having a hard time imagining it working as you say that it is. DHCP isn’t supposed to work that way.

From your description its not clear where its failing. Do you see the iPXE menu but when you select registration or such that is where you are seeing the attemp and the NAK?

I clear picture taking with a mobile phone would help set the context.

The target computer should only pull a dhcp address from the current subnet. There is no way that I know (outside dhcp reservations) to get an IP address outside of where the client is currently located.

If the client is being told something unexpected we can use wireshark with the capture filter of port 67 or port 68 to only capture the dhcp traffic. That wireshark computer only needs to be on the same subnet as the pxe booting computer to capture the traffic. I sure would like to see that pcap to better understand what the target computer is doing. You can either upload the pcap here, or upload it to a file share site and IM me the link and I will take a look at it. Please don’t mask out IP addresses because it makes it much harder to see who the actors are.

@nerdstburns Please take a picture of the error in screen and post that here. The notice on space is only a general message and does not necessarily apply in this case.

@nerdstburns Since the pxe booting computers are on a different subnet than the fog server, you will have to go the wireshark route.

Install wireshark on a 2nd computer on the gamers vlan. Setup a capture filter of port 67 or port 68 and then pxe boot a computer until you get the error.

The stop the wireshark capture. You should see a dhcp DISCOVER from the target computer and then one or more OFFERS from dhcp servers that heard the DISCOVER packet. Make sure you know these responding dhcp servers if you have more than one answer.

Look at the OFFER packet (in the center section) and expand it there should be an ethernet header section where you would have …

It may be just easier to post the pcap here or to a file share site and IM me the link. It would take me twice as long to type out what to look for than for me to just look at it.

@nerdstburns said in Updating Fog Server 1.x.x:

will I have problems updating to a stable version if I have 1.5.9RC2?

No you will not have issue the only thing you will need to do to switch back is this

git checkout master git pull cd bin ./installfog.sh

The current 1.5.9RC2 is very stable and there will (probably) be no (true) difference between 1.5.9RC2 and 1.5.9 GA other than the name change.

@D-Bandit Please check the state of the service by running systemctl status FOGSnapinReplicator. So you see any errors there?