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.
Yes, if you wouldn’t mind please. I will prep a box tomorrow with default installs and restore the backup. Will then run through and let you know what I come up with … or if it all decides to just work.
Thank you.
Thanks for your additional details.
Initially when checking into this error, I did replace the bzimage w/ a clean on from the working test server. I assume that the bzimage was again replaced when I updated from 1.5.5 to 1.5.6. It may have been my typo on the bzimage text.
I will load the corrupted backup onto a test box and see what comes out of it and check the URL posted.
Thank you.
Thanks for the follow up. Yes, it is one of the things I tried.
As a follow up to this, I have restored fog from a previous backup (Jan) and all now works - tested both pxe and uefi boots - capture and restore.
I will leave this as is, as it now works. I did save a damaged config export to play with later if needed.
Thank you.
Server:
• FOG Version: 1.5.6
• OS: Ubuntu 16.04.6 LTS
We are looking to move over to UEFI next summer and have started testing. Our initial tests over a break were successful and we were able to capture and deploy via UEFI boot using FOG 1.5.5.
Sometime between then and a couple weeks ago, we are no longer able to capture or deploy. No changes have been made between the initial and failed tests.
We are using ipxe.efi as the boot file. When booting the client, we get the error:
...
tftp://fog-node-ip/default.ipxe... ok
http://fog-master-ip/fog/service/ipxe/boot.php... ok
bzimage... ok
Could not select: Exec format error (http://ipxe.org/2e008081)
Could not boot: Exec format error (http://ipxe.org/2e008081)
Could not boot: Exec format error (http://ipxe.org/2e008081)
Chainloding failed, hit 's' for the iPXE shell; reboot in ... seconds
When again taking a further look at this, fog was updated to 1.5.6 - hoping the update would resolve this issue. After updating, we have again tried to capture / deploy and the same error (above) is displayed on the client.
As a test, I have build a fresh version of fog (with no nodes - v1.5.5) and when pointing the test server, we are able to capture an image. When deploying, the client goes right to the refind_efi menu and not the fog menu…
I have gone through and checked permissions, ownership and settings between our production fog and our test fog. I have not been able to find anything that would point me in any direction to figure out what may be going on.
I have gone through the BIOS settings on the client (secure boot off, TPM disabled, etc.). I have also tried different variations of this based on other discussions on this forum for the errors received. Unfortunately, many of the other posts have not helped to move me in the right direction.
I would like to see if there are other things / ideas I am able to check / try in the hopes of resolving this. Please let me know should additional information be needed.
Thank you for your time.
@Wayne-Workman
Thank you. Yes, that was read several times. 
Seems it didn’t infiltrate the brain properly enough to be effective.
@Tom-Elliott
Thank you for the quick reply. I am sure it is what happened the fist time. I will properly give myself a double face palm.
(ლ‸－)(－‸ლ)
I did read in bold about that and thought I had removed the password and denied saving for fog. In the assumption that it did auto fill the second time - would updating with the same password still result in the error?
I have changed all passwords to be the same - aside from sql, so if autofill did kick in, it would have entered the same password…
In any case, things are working and if I am feeling brave enough, I will try again from a clean browser or incognito.
Thank you for you time.
Mark
Server:
• FOG Version: 1.4.2/1.4.3
• OS: Ubuntu 16.04
Client:
• Service Version: 0.11.12
• OS: Windows 7
Description:
After changing max clients in our nodes, I ran into the issue that snapins and images would not sync. The log for both images and snapins shows the following error:
Type: 2, File: /var/www/fog/lib/fog/fogftp.class.php, Line: 463, Message: ftp_login(): Login incorrect., Host: Username: fog
After some digging through these forums and finding the same error (via a different cause), I have changed the passwords to match on:
• .fogsettings: on main FOG
• Node: (Storage Management > Management Password
• GUI: FOG Settings > TFTP Server > FOG_TFTP_FTP_PASSWORD
• CPU: fog user password
After performing the above:
• received same error after restarting main FOG
• received same error after restarting node FOG
• received same error after re-installing (and restarting) main FOG
After re-installing and restarting FOG on the node, the issue was resolved and syncing again began to again work. I re-installed on the second node and syncing to that server was also restored.
Not sure if I’m missing anything as the issue came up again when I additionally changed the Max Clients on the node (and main FOG). (The first time this happened it was late and in reaction mode - so I was not able to pinpoint the cause). The second time, it was the only change made and I noticed the same error and issue appearing - so I am assuming it is related to the Max Clients change on the node (via GUI).
The resolution for me was same; to re-install the node, not main FOG - though I also did re-install main FOG.
I am wondering if there is something I have overlooked or missed to prevent this from happening again… perhaps a permission change? I am worried to change max clients again as we are rolling into summer and things are currently back to normal and working as expected (wonderfully). Will be able to break again after the summer refresh to get more details if needed.
Anything to help find the root cause or to look at prevention is appreciated.
Thank you for all the great work.
Mark
Maybe not related, but ran into something similar from 1.3.5-RC10 to 1.4-RC4 upgrade. After installation, when requested to update the schema - only a blank page was shown. To get to the scheme upgrade page, I needed to enter the full path (http://xxx/fog/management/index.php?node=schemaupdater).
After installation was complete, the normal http://xxx/fog/ did not resolve to the normal http://xxx/fog/management/index.php login page. The page would work as expected if manually entering the full path.
I resolved this by changing the apache dir.conf list order. index.html was listed first. I placed index.php to the front. After doing this, going to http://xxx/fog would redirect properly and read the .php index file.
Thank you (all) for all the great work!
Mark.
Organization Name: The British School in Tokyo
Location: Tokyo, Japan
Approximate Number of Systems: 550
FOG user since: 0.27
Great work, great support, great team, great community! Thank you very much for this. The team and I thank you for giving us our summers back!
Kind regards,
Mark
@Tom-Elliott @Wayne-Workman @THEMCV
Thanks for this. Worked successfully for me. Will be trying the image ID one once next years image(s) are done. Thank you again!
Would love to join… not sure if any time would work for me… 10AM EST Sat is Midnight Sun for me (JST). Perhaps an hour earlier…? or 9 hrs later?
Thanks for the updated feedback. I will look into the hiding the password as suggested - the script I wrote is probably crude and ugly.
I have another (unrelated) question to ask, but tomorrow and on a new thread.
Thank you again for your time and appreciate the great help and support.
Mark.
I have tested and successfully deployed snapins in my method of choice. I have elected to use @george1421’s option as having an exposed share in our environment is not my first choice.
Thank you for your help and pointing me in the right direction. I greatly appreciate it.
Mark
Thank you for the reply. I will give both a go and report back.
Appreciate the help!
Thank you again,
Mark
While not the ideal “FOG” way of doing snapins, I am having issues using a powershell script to download a file from a remote local server. Under Fog 1.2.0, I did not have an issue with the ps1 (or bat) script copying a file from a remote server to the local disk.
I have a .bat file that is added as a snapin. The .bat file contains a command to copy a file from a network share and then execute the downloaded file.
The issue I am having is that the file does not get downloaded.
FOG registers and runs the snapin without issue - local commands stored within the ps1 file execute correctly. The only area that doesn’t work is the request to download the file from the server.
The script also runs without issue when manually run from the local computer. (It copies the files and executes the downloaded file).
The remote server has a shared folder. Trying AnonymousLogon, Guest, SYSTEM with full (and read only) permissions has not allowed me any further luck in downloading the file.
Looking for clarity on how I might be able to download a file from a server from a powershell script run as a snapin.
Please let me know what additional information may be needed to assist with providing further help with this issue.
Thank you for your time,
Apologies for not being specific. ‘Return’ meaning the error experienced from this thread. I am also experiencing ongoing inconsistency with snapins deploying, but is something I am looking into separately.
Thank you for your follow up, quick replies and great work!
I have confirmed that the firewall is disabled on the main fog.
Noticed that RC16 has been released, will try to update to that release tomorrow and see if any of these issues have returned.
Thank you for your time and help!
Sorry, didn’t see this earlier.
No firewalls or filters are running on the machine. I will reconfirm tomorrow when back at work.
I have been able to image a machine via the node and all worked as expected - though having an issue with Snapins. Will check this later – one thing at a time.
Thank you again for your time.
I have checked through and found the configuration file in /etc with the ‘bind-address’.
As you have mentioned, it is commented. The bind-address gives the value of 127.0.0.1.
My apologies, however, if you would again advise what I need to do with this… should I un-comment this line? Or change to the IPv4 address instead of the loopback? Or is this to confirm that the line is commented?
Please let me know.
As of now, with the steps recommended by @Wayne-Workman, fog is running and able to see and provide information on the nodes - will be trying a deploy and upload later today to confirm all is working nicely.
Thank you for your time.