@george1421
New revelations have been made. As I said I now replicated the whole setup on a local isolated network (with exception of the apparmor modifications, not necessary on a bare-metal installation).

I have my witness-computer connected to both networks with 2 seperate NICs. Only one is active at a time. In both setups I first started wireshark on the witness computer and booted a notebook into pxe.

Main network: No packets or barely some DHCP-ACKs (that were not from the booting laptop). Isolated local network: Discover -> Offer -> Request -> ACK. Laptop got an IP from the router and loaded the appropriate bootrom from the fogserver and booted from it.

Conclusion: Since the witnessing of the DHCP-packets have nothing to do with fog itself it is safe to say that there is some sort of broadcoastfiltering of the DHCP-relevant ports. The (almost) exact same installation worked in an isolated network but not on the main network.

Thank you so much, I finally know the exact cause of the problem and am able to proceed. I now have to write up a request if the networking team would be so kind to allow the broadcoasting of those port-packets to a single static IP that I own (I really hope they’ll allow that. Now that I think of it this makes total sense. If people are able to plug in their own devices into the network that behave like a DHCP-Server and then handle the IPs before the main DHCP does you are in a golden MITM-position and can intercept with the network-packets to your desire). But as far as fog goes, this is nothing from its side.

So I think I can say this is solved for the cause of “troubleshooting”. Even if my journey is not exactly at its end yet. Thanks again!

@Sebastian-Roth Thank you very much. We had an outage last week so I didn’t have time to follow up. I just upgraded to latest dev-branch and things are working now. Advanced menu is working as it was before. Thanks everyone involved!

It seems like for the most part this worked. Thanks for your help @madeyem ! I suppose this is solved now.

@Sebastian-Roth

I have built a vanilla box, installed fog and restored my configuration … and it all worked! I was able to boot via pxe and uefi on the first try of each.

I will chalk this up to both the blank mysql password and a miss named bzImage file. As it is all working with the “bad” backup config, I will ask that this ticket be closed. One day, if I’m bored enough, I’ll try another restore again and see if it will fail.

Thank you for all the help! It is greatly appreciated.

@Sebastian-Roth they recently changed some thing to get to the internet i had entered credentials when first setup this server they must have done an update and I did not get the prompt to enter new credentials all is good now. Thanks for your help!!

@george1421 I’m using ipxe.pxe as the boot file. Not replacing the version VB’s NIC’s are set too. (Though I imagine that would work well too.)

@Scott-B Be aware that I just re-added the #!ipxe stuff as other users told us the advanced menu is broken for them now: https://forums.fogproject.org/topic/13230/advanced-menu-bug

This is only in the current development version but it will also be in the next release 1.5.7. Just so you know in case you update to that or a later version at some point in time.

@Junkhacker Done 🙂 https://github.com/FOGProject/fogproject/commit/f943e3a8690110fd7b469b40e38f3d26512ddc18

@jmonroew71 Take a look at the log file in /var/log/fog/fogmulticast.log and post the contents here.

I can imagine you are in the same situation as others with this: https://github.com/FOGProject/fogproject/issues/268

@rzuchowski Try connecting a dumb (unmanaged) mini switch between the client and your building switch and try again. It’s very likely a spanning tree issue.

If it still doesn’t work tell us your FOG server IP and post a picture of the error on screen.

Thanks, i have forced the install and it’s ok.

Bye 😉 !

@george1421 I have rerun the installer and all seems to be fine for now. thanks for the help.

@kratkale You are welcome. It’s good to have people around who rapidly test things that we push out. 🙂 Thanks to you!

@Sebastian-Roth said in Fog Menu loop:

Would it be possible to prevent from this issue when returning and empty string instead of nothing when the key in globalSettings does not exist?

I don’t know about how fog interacts directly with the database but MSSQL has an ifnull statement where if the field is null (or missing in q joined table) you can return a specific alternate string. It appears that mysql has a similar construct.

@Sebastian-Roth WhatsApp Image 2019-05-04 at 15.35.11.jpeg WhatsApp Image 2019-05-04 at 15.34.44.jpeg
25 an 36 PC in Multicast

@george1421 That was the problem! Thanks!

@Sebastian-Roth said in FOG unable to capture/deploy resizeable images correctly.:

@dambron Yeah, Quazz is totally right. We have updated the init files and I totally forgot to ask you to try out the most current ones (32 bit and 64 bit). Hope this will fix the issue for you.

Thanks so much to both of you. I replaced the init file and everything is now working properly. Many thanks for your time and efforts.

@Sebastian-Roth
My apologies for not being clearer in my message. I realized here in the past hour that the files were missing after running the terminal commands that removed the old web data. I put the files back and our links are now working again. All issues are resolved and we appreciate your assistance in making it happen.

@nvdp2002 The last we see in the log is Is the MySQL password blank? (Y/n) - how do you answer the question? Do you know the password of your database? Is it blank or set?

@Sebastian-Roth Thanks for taking a look. I lowered the max bandwidth that the replication can use so it would not crush our link and allowed it to run all night. The images have replicated and traffic has dropped off. again thanks for the help. I think everything is working now.