@george1421 said in Recreate Fog account:

exit;

george1421,

That worked, back in business.
Thank you very much for the assist.

@Sebastian-Roth
Ok thanks.
Waiting, workaround for us is to use SUN, MON, TUE, WED, THU, FRI, SAT instead of number for Shutdown and Reboot

Resyncing the fog service account password fixed my problem. Thanks, george1421!

@khalid said in unable to install with snapin:

this is an .exe file that runs perfectly on my local machine with just a simple … next next

You need to make this a so called silent install that can run without user interaction!

Here find some hints on the command line options you can use: https://installer.netbeans.org/docs/cli_options.html and http://wiki.netbeans.org/NetBeansInstallerTipsAndTricks#Simple_silent_installation_with_customization

Might be easier at this point to just do a complete re-install of the machine. I’m not sure why the partition table looks the way it does, but starting from scratch is sometimes the easiest bet.

This time I’ll start in the VM environment.

@lucas942 said in Nas node storage : permission denied:

I just got to find a directory in / images on the NAS 14gb its name is: e86a64cbxxxx and this corresponds to the MAC address of my PC.
So I rename this folder “Standard”?
Because the name of my image is “Standard”

You have a few things that are wrong.

The image file should be first captured into the /images/dev/<mac_address> folder. After the image is fully uploaded to the /images/dev/<mac_address> folder the target computer logs into the FOG server (nas in your case) via FTP and issues a move command to move all of the files in /images/dev/<mac_address> to /images/<image_name>.

The screen shot of the error you see about ftp_put tells me that in the storage node configuration there is 2 fields Management Username and Management Password. The values in those fields must match the user you created on the NAS device.

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