Well rebooting the switch does seem to have had some effect, this batch are now multicasting at 2Gb/min. I’ll look at getting it replaced, it’s a noisy beast anyways.

@danieln Correct as long as bzImage and bzImage are what you want then the proper kernels will boot.

@george1421 Everything is OK now. What we missed that our fog servers have different from the labs NAT and we needed to add rules for every NAT address in the Firewall on 80 and 443 ports. You can close the topic. Thanks

@phm2000 I don’t know that model but I did find that your switch does support “green ethernet” mode. I’m not saying that this IS the problem but if your only solution is to disable STP then I would look to see if green ethernet is enalbed on your switch. According to this article its disabled by default: https://community.hpe.com/t5/Comware-Based/How-to-disable-IEEE-802-3az-Energy-Efficient-Ethernet-feature-on/td-p/6896946# Look at the accepted solution.

Disabling STP on user facing ports is not the best choice. You may need to get with a switch engineer to understand why turning on RSTP does not solve your problem (because turning off STP solves the net booting). From your description it sounds like the port is in standard STP mode even if you set it to RSTP. I assume (with RSTP on) placing a dumb (unmanged) cheap switch between the building switch and the pxe booting computer will also mask the problem. We will typically recommend this for people to test to see if the problem is spanning tree or not without changing the switch settings.

Edit the file /opt/fog.fogsettings and replace the IP address there.

Then edit the /tftpboot/default.ipxe file

in the fog settings and default storage node change the IP there.

Finally rerun the fog installer once again to fix the rest of the bits.

@sckendall said in Fog ProxyDHC with Fog and Pfsense on the same network:

Well, the question is whether it is possible to have two independent fog servers on the same network.

Well this sentence changes everything.

If you want to pxe boot on your laptop you will need an isolated network or if you are running a hypervisor on your laptop then you can create an internal network.

I just think of an idea. Its possible if on your main FOG server, you create a custom FOG iPXE menu that links the fog server on your laptop. Then normal pxe booting to main fog server, then chain (ipxe command) to your FOG server. That is possible.

hello,
I found the solution.
looking at the databases, there are 5 fields on the fog 1.2.0 base and there are 9 fields for version 1.5.9.
so the hots don’t appear.
by importing the database on the new server and importing the csv host everything is ok.
the export of the csv on the 1.2.0 server was with the separator ,
I reworked the file with free office to put it in ;
it works.
I leave the solution here for old fogs who want to migrate to a new machine 🙂

@george1421 That did the trick!

I had previously added the images2 *(ro etc;etc;etc;) but did not run the sudo -exportfs -a command.

I knew it was something simple. Thanks so much for your help!

@aschaffer What do you mean by “needs to be touched”?

By the way, this topic is years old and you might want to create a new one and post all your specific details there like version and a detailed description…

@rogalskij The FOG developers are expecting the Linux kernel developers will take 5.10.x to LTS status. When they do the FOG developers will make 5.10.x the standard kernel in FOG. ref: https://www.kernel.org/

FWIW, there was quite a few new drivers added to 5.9.x series (almost as many as was added to 5.5.x), so 5.10.x LTS can’t come fast enough because FOG will start running into that hardware soon.

@sebastian-roth said in ipxe/boot.php and bzImage running very slow:

@danieln said in ipxe/boot.php and bzImage running very slow:

The only change was that I added one additional storage node.

Storage node being in the same subnet as well?

Correct. I double checked and it is on the same subnet.

@geardog Two things from the tutorial I just want to point out:

Make sure its at least version 2.76 by issuing this command at the fog server’s linux command prompt sudo dnsmasq -v. The version needs to be 2.76 or later.

and as George already mentioned here:

Be sure to replace <fog_server_ip> exactly with the IP address of your fog server. Be aware that <fog_server_ip> appears multiple times in the config file.

@huecuva said in Hanging on ipxe initalizing devices.:

Can those iPXE binaries be changed in the webgui?

No because it all depends on the DHCP server you actually use in your network (quite often it’s not on the FOG server itself).

@rubensurtfe-0 As soon as the boot files are sent to the target computer, the FOG server is no longer involved with the target computer. SO this error is with what ever OS is running.

@george1421

Now you said that isc-dhcp server worked?? The reason why I ask is that isc-dhcp server and dnsmasq do the same thing. So why would isc-dhcp server issue IP addresses and dnsmasq does not respond?

To be honest, this is beyond me.

Initially, when I configured the FOG server I installed isc-dhcp server, configured pool of addresses and added “next-server” and “filename”. Then I set bootprelay of the switch to point to the FOG server and everything worked (and still works if I go back to this scenario).
Afterwards I realized that our expensive switch supports dhcp and decided to give it a shot (why use separate service for something that already runs on the switch, right?). Since then I’ve encountered this issue i.e. switch supporting only numerical option codes (66, 67 etc). Analyzing the frames turned out that my clients are unable to evaluate those options even though they do exist in the dhcp packets! Having “next-server” and “Boot file name” in the packet body seemed like the only way it works. I managed to confirm this by analyzing frames coming from my working isc-dhcp server.

Now, you can probably see how strange it is.

@active-pcb I guess the partitions were set to use a fair amount of the disk space for /home when you installed Ubuntu. Run sudo fdisk -l and post output here in the forums.

@nerdstburns Adjusting compression ratio with Zstd might help to speed it up.

Thank you!

@sebastian-roth @george1421 I may have posted this thread prematurely. I ended up having my colleague try a different type of Ethernet dongle (USB-C vs regular USB) and that did seem to fix the halting issue. I can verify tomorrow, but I think that message in the picture is still there, it just keeps imaging until complete now. I also found out a nice new BIOS came out for this model, so it is possible an update can fix the message. I can test the bios update with one at some point, but we are pretty busy with students returning next Tuesday in person.
I think we can mark as solved in the meantime.

Thank you - That is helpful. It seems the persistent groups plugin works more along of the line of what I expected from the default groups.

It seems then that it is not possible to have snap-ins defined as defualt, associated to an image or ALL hosts regardless of groups? Perhaps that goes against what a ‘snap-in’ is reallly intended for…