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?

@jenesis

I have resolved the issue , on my Nic configuration i had more than one IP Adress set , and that confused the ssl key creation process.
Once i went back to one ip adress , the keys were created and the setup complete.

I had to install fog through Squid proxy that i have setup , just for that. Because of the way my network is built.

Hope this helps some one.
Chears

@Mr_Jay84 Just be aware that if you want to pxe boot across subnets, then you will need to add the fog server as the last server in your vlan router’s dhcp-helper/dhcp-relay service. Once you do that then you can pxe boot across subnets if you need it.

@Sebastian-Roth said in New fog installation, stopping web service failed.:

@berndttoast23 said in New fog installation, stopping web service failed.:

Thanks for your reply, I took your advice but unfortunately it produced the same result. Any other ideas?

Did you really pull the very latest version via git?? As mentioned by George this changed was pushed only a few days ago and it’s not part of the last RC version but only the very latest from dev-branch.

Thank you @Sebastian-Roth! That worked!!

It’s working ! 🙂
Thanks.

@Sunks The screen shot you provided is the end results of what happened. It doesn’t really tell us the error itself.

So here is what I want you to do.

Schedule another capture/deploy (what ever you were doing) but before you hit the schedule task button, tick the debug checkbox on that same screen. Then pxe boot the target computer. You will be presented with several screens of text that you need to clear with the enter key. Eventually you will be dropped to a linux command prompt. This is debug mode.

Now we are going to single step through the capture deployment process. The process will pause a breakpoints in the code. You will need to press the enter key to move to the next breakpoint. You want to view the partclone screen(s). The error message will be scattered about the partclone screen, typically with white text with a black background. We will need to see this error. Grab a screen shot of this partclone error and post it here.

To start the process key in fog at the linux command prompt.

@george1421 Thank you for all your help!

I was able to get it to boot consistently by changing some adapters on the VM.

For the capturing image issue i resolved that as well.

An error has been detected!
Init Version: 20200517
e2fsck failed to check /dev/sda1 (shrinkPartition)

The solution was to remove the capture task and replace it with a debug task. Once in debug I ran fsck on the /dev/sda1 partition. Then I changed the image to Multiple Partition Image Single Disk Non resizable in the web GUI on the fog server.

Thanks again for all your help.

Jon