Moderators

@chvys10matt said in halts at "configuring":

Well if you are a friend of Zerpie then you are a friend of mine…

We have see that on a few hardwares where it will lock up at initializing devices… I can tell you I have experienced it personally with a Dell 7010 in uefi mode. There is no way around it, there is a problem in the uefi firmware on those 7010s. The easiest way around this for the 7010s is to go into the F12 boot menu and have the target computer boot in bios mode for imaging. You can clone a uefi based image while the pxe booted computer is in bios mode.

If you are experiencing this issue on another hardware model, the first suggestion is to make sure the firmware (bios) is up to date on this computer. Also make sure that secure boot is disabled on the target computer.

@Seydoo said in No DHCP after PxE Menu:

I have to find where the issue is

So the questions are now:

1. Is the switch connected to physical server the same model as where you have problems?
2. Are the two switched configured the same way. I can understand that switches where end users are you would want to have spanning tree enabled, but in the data center when there is no chance of a loop back its not needed.

@Seydoo said in No DHCP after PxE Menu:

I am really convinced of a network problem (snapping tree for example), but I can’t prove it and it annoys me because without it, I can’t ask the network team to solve my problem.

Well that dumb switch is the easiest and best way to prove it. What I suspect is going on here is as the pxe booting computer boots, it will momentarily drop the network link ask each kernel hands off control to the next one. You will see this network “wink” when the PXE boot ROM hands over control to the iPXE boot kernel, and then again when iPXE hands over control to the FOS kernel (bzImage).

Now where spanning tree comes into play is if standard spanning tree is used, standard spanning tree uses pessimistic blocking in that it won’t forward any data until 27 seconds after the link goes up. During this 27 seconds its listening for duplicate BPDU packets. If it hears none then it starts forwarding data. If one of the fast spanning tree protocols are used (fast-stp, rstp, mstp, etc) they use optimistic blocking in that they start forwarding right away while listening for a duplicate BPDU packet.

The problem is this, if standard spanning tree is used, that 27 second delay before forwarding to too long of a time. FOS boots and is ready to go so fast, but the time 27 seconds come and the port starts forwarding data FOS has already given up trying to get a network address. But if you boot into debug mode and issue the udhcpc command, that is probably after the 27 second timeout and it gets an IP address like it should.

That is at least that’s the way I see why it’s not working.

Lets start out with 2 questions:

1. If you place a functional windows computer on this same vlan does it get an IP address?
2. If you place a cheap/dumb/unmanaged switch between the pxe booting computer and the building network switch can you image every time?

My experience is telling me if you don’t get an ip address during FOS startup, but can issue the udhcpc command at the command prompt and get an IP address then its probably a spanning tree issue. Question #2 from above would prove that out.

@ethan-s Why yes I do: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

If your pxe booting clients are on a different subnet than the FOG server then you will need to update your dhcp-relay service on your vlan router by adding the FOG server as the last dhcp server in the dhcp relay list.

@ethan-s Some (crappy) routers will give out their address instead of the defined next-server address. You should be able to see this if you setup wireshark on a witness computer. Use the capture filter of “port 67 or port 68”. PXE boot the target computer until you get the error then stop wireshark. Look at the DHCP OFFER packet and look to see what next-server is set to.

If your router isn’t capable of handing out the proper pxe boot information then we can load dnsmasq on your fog server and have your fog server only provide the pxe boot information. The rest of dhcp would be provided by your current dhcp server. So even if you have a misbehaving dhcp server we can get you going.

@lalo Here is how you set it up

1. Services->DHCP Server
2. Select the interface where the dhcp server is running
3. Scroll down the page and select the network booting button.
4. Fill out the form as below
   

@lalo said in PFSENSE!!!!! is great:

tendrás una metodología de instalación y configuración del servidor fog y pfsense…

The connection between FOG and pfSense is pretty simple. I guess that you use pfsense for dhcp server? If so there are only a few fields that must be filled out. I can provide a screen shot of the settings in about 1 hour if you need them.

@Fernando-Gietz We use nagios (Centreon to be specific) for monitoring our environment. It doesn’t do the charting like mysql workbench, but you really need to ask what is important to monitor otherwise you will just get a bunch of nuisance messages.

I could go more into the philosophical side of system monitoring, but I think right now you are looking for a tool. If you have a budget then solarwinds has very nice monitoring tools, but you will pay for them. If you are looking open source then nagios/icinga are the leaders.

@Baessens Yes and no. FOG will replace the image files, you will have to export and import the metadata from the web gui. Its not directly supported by FOG but is workable. You just setup the remote full fog servers as a storage node to your root FOG server. The root fog server will then replicate the images to the remote fog servers. The only thing it won’t do is update the images table on the remote fog servers. But you can do that via an export from the root fog server and import into the remote fog server.