https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node

Essentially that will do what you’re looking for.

You do not install the fog software directly. You just need to configure the node to have FTP and NFS.

You will miss a few little details such as disk size and what not.

@Hartman4820 said in fog capture stuck at starting cmain:

starting cmain

This message is only being displayed by GRUB chainloader as far as I know. What this means is that the host your are PXE booting is using GRUB to chainload the OS from your hard drive and therefore I am sure there is no task even scheduled for this host!

You are saying “I check the Tasks and it just stops the task.”. Can you please let us know how exactly you scheduled the task and if you get to see it in the tasks list at the very beginning?

Just started a new fog server.

Which version of FOG do you use?

@george1421

Great thankyou, will do as you’ve suggested and report back!

@george1421 I’m good now. Thanks

@T-thorel Ok you passed the dhcp issue and pxe boot issue. Now the issue is with the iPXE program that creates the FOG iPXE menu.

Typically when we see this error it is because your building network switch is using Spanning Tree protocol but not one of the fast spanning tree protocols. A test for this can be to find a dumb/cheap/unmanaged switch and place it between the pxe booting computer and then building network switch. If the computer pxe boots correctly into the FOG iPXE menu then you will need to get with your networking/infrastructure group and have them enable one of the fast spanning tree protocols like portfast, RSTP, MSTP, fastSTP, or what ever your switch manufacturer calls it. This setting will need to be enabled on every user facing port where you need to pxe boot.

The issue is that FOG boots too fast. It will give up trying before spanning tree starts forwarding data on the network interface (~27 seconds after the link light is turned on).

@f-15s-mtd You will need to change every switch/port that has a device that you want to pxe boot on. This is an access layer issue not something related to the FOG server or switch to switch communication. The problem is in the “last mile” so to speak.

ref: https://community.cisco.com/t5/other-network-architecture/enable-portfast-on-all-ports/td-p/324511 read down the post because there are switch global commands that you can use.

@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?