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

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

@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

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

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.

@Sebastian-Roth

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.

@george1421

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

@Tom-Elliott

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