step by step of fog imaging start
-
Hi!
Can I ask for a help? We need a network help to improve our fog possibilities (we had issues, what is not fog based, but network based what prevents some things to happen during fog). The support (outside help) is not a fog specialist, so asked us to get as many information as possible to detect the problem. As a part of it, I would like to give them the info about the fog booting process. From ipxe to partcloning.
Can I ask for the steps of the boot process? I dont need bit depth, but to detect the problem, I would like to give details as much as I can. Like: “network boot, ipxe dhcp starts, then…” and so on.
(we have issues of these steps with some hw, before image starts to deploy the actual hdd, but it is strange, and not fully global. maybe some of our hw is not properly working in our network, or idk).
I would appreciate any details and helps. Thanks in advance
-
FOG uses all opensource tools to support imaging. These tools include dhcp, tftp, iPXE boot loaders, and a customized linux operating system called FOS (Fog Operating System).
The imaging process starts out with the PXE rom on the target computer. This PXE rom is responsible to dhcp boot the target computer and download the iPXE boot loader. The target computer sends out dhcp DISCOVER packets and the dhcp server responds with an OFFER packet in that OFFER packet the dhcp server sends the boot server and boot file names. The boot server in FOG’s case is the IP address of the FOG server. The boot file for uefi would be ipxe.efi.
At the end of the dhcp process the PXE ROM will then request the boot file from the boot server over the tftp protocol. In FOG’s case the uefi system will download ipxe.efi to the target computer and start that boot loader. At this point the PXE ROM (built into the target computer) exits memory as iPXE (an advanced version of the PXE ROM) takes over control of the target computer. The tftp protocol is no longer used from this point forward.
The iPXE boot loader then issues another dhcp DISCOVER process so it can learn how to find the boot server (the fog server) from the dhcp process. The iPXE boot loader contacts the FOG server to see what it needs to do. iPXE uses the http protocol to talk with the FOG server. The iPXE boot loader is responsible for managing the FOG iPXE boot menu.
Lets assume that target computer has already been registers and you have selected to image the target computer.
When the iPXE boot loader starts it contacts the FOG server to see what it needs to do (display the iPXE menu or image). With a scheduled task the iPXE boot loader sees that imaging is selected. At this point it doesn’t display the FOG iPXE menu, but instead it requests the FOS Linux operating system from the FOG server over the http protocol. In this case the iPXE boot loader requests the linux kernel (bzImage) and the virtual hard drive (init.xz) from the FOG server. Then the iPXE boot loader launched FOS Linux then exits memory.
Now that FOS Linux has been loaded onto the target computer it starts up again issues a dhcp DISCOVER to get its IP address from the dhcp server. The FOG server sends instructions to the FOS Linux engine using kernel parameters sent during the bzImage transfer process. With this information the FOS Linux engine starts to do its image cloning process.
From an infrastructure standpoint if there are any firewalls or screening routers that block traffic between the FOG server and the target computer that will cause problems with communications.
Another issue we see is that some networking switches have standard spanning tree (STP) enabled. This causes a problem with FOG because the imaging process (from target computer power on to FOS Linux requesting a DHCP address) is very fast. Its usually less than 15 seconds. The standard spanning tree listens on the network for a BPDU packet for 27 seconds before it allows the port to start forwarding data. By the time standard STP starts forwarding data the imaging process has already given up because it could not get a dhcp address. This 27 second counter is reset every time the network link is dropped. The network link will be dropped (wink) at least 2 times during the pxe booting process. Once as the PXE ROM exits and iPXE boot loader takes over and once when the iPXE boot loader exits and FOS Linux takes over. A test to see if standard spanning tree is a problem is to place a dumb (low cost unmanaged switch) between the target computer and building network switch. This unmanaged switch typically don’t support spanning tree and will keep the building switch port link from (winking) as the PXE ROM exits as well as the iPXE boot loader. If the unmanaged switch fixes the issue then have your network support look at the building switch to see if one of the fast spanning tree protocol can be enabled. The fast stp protocols will start forwarding data right away while listening for a BPDU packet. This solves the dhcp DISCOVER issue.
-
I really appreciate this, really detailed and helpful. Most of this was in my head cos of many reading and usage, but I think I would messed it up with failing memory, forgetting 1-2 things out. You guys, are still in any kind of support!
-
@Foglalt Beside George’s great and thorough answer you can also read through this as well: https://wiki.fogproject.org/wiki/index.php?title=Booting_into_FOG_and_Capturing_your_first_Image
