working-1.6 ... During image creation: Updating Database ..... Failed

[jms]

Running image creation task … using working-1.6 (pulled within the past week) … after image creation complete, I get the dreaded “updating database … failed … retry etc etc etc”

I have followed all instructions regarding permissions of /images (chmod -R 777, chown fog:root), and I have followed all instructions related to passwords.

I have updated “fog” Linux user password using passwd and have updated the storage node configuration, the fog ad user/pass and the fog tftp user / pass. I have also updated /opt/fog/.fogsettings.

I get the following error in php-fpm/www-error.log …

[09-Nov-2018 02:06:30 UTC] PHP Warning: ftp_delete(): Delete operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 106
[09-Nov-2018 02:06:30 UTC] PHP Fatal error: Call to a member function rename() on boolean in /var/www/html/fog/lib/reg-task/taskqueue.class.php on line 362

And yet, from my Mac desktop I can use Filezilla to successfully ftp to my fog server using the user/pass that I have setup everywhere else and can traverse the entire filesystem remotely via Filezilla and the fog user credentials, so I know that vsftpd is working.

When I monitor /images/dev during image creation … the image is actually xferred and saved in a directory there.

What can I try next? No other logs appear to have anything of consequence, but I could be missing it I suppose.

Of note, my mysql db is running with no user/password as allowed during fog setup - but I can easily access the db using ‘mysql -D fog’.

I’m running on CentOS 7.5.

[Sebastian Roth]

@jms This should help you: https://wiki.fogproject.org/wiki/index.php/Password_Central

I am wondering if this is really a “working-1.6” issue?!

[jms]

Ok, that page has some useful tips, although the mysql portion(s) are a bit circular regarding the number of different mysql users required. Is there a single mysql user/pass for everything in fog, or is the storage node mysql credentials different?

I did not set a password for mysql during installation.

.fogsettings shows no user/password/host for snmysql*

Web UI shows a user of “fogstorage” along with a password for FOG_STORAGENODE_MYSQLUSER/MYSQLPASS

config.class.php shows a user of “root” and no password under function _dbSettings, and shows user “fog” with the correctly set password for STORAGE_FTP_USERNAME/PASSWORD, as set by passwd for the Linux system user “fog”

When I run the mysql credentials test with no user/pass against the fog db it works fine, but when I try against the storage user listed in the Web UI I get the following …

[root@fogsrv ~]# mysql -U fogstorage -pPASSWORDHERE -D fog
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

[jms]

Update. I created 2 identical CentOS 7.5 vm’s, configured them 100% identical.

On on I installed fog from the git clone and on the other I used git to checkout working-1.6 and install. All fog installation parameters were exactly the same for both servers.

On the regular git cloned fog installation, everything works as expected.

On the working-1.6, I get the same error as before, after image captured, updating database … failed.

So I agree, something with 1.6

I’m happy to help troubleshoot further. I’ll poke around on my own but if there are some things you would like for me to try I’d be happy to participate.

Thanks !!

[Sebastian Roth]

@jms Thanks heaps for digging into this! I don’t seem to find the time to test myself in the next couple of ways. Would you mind doing another test for us? Try the very same but this time to a git clone ... followed by git checkout working (1.5.x working branch). Same issue?

[jms]

@Sebastian-Roth I tried against “working” branch (1.5.x working), setup identically to the other 2 VMs and fog installations, and it works flawlessly, same as stable (head? – sorry I’m not that up to speed on git terminology!) … so, seems the issue lies squarely in working-1.6

Happy to continue to test and debug - just let me know how I can help.

[Sebastian Roth]

@jms Thanks again for testing and reporting this. Turns out to be a bug in the working-1.6 code which I did not know about as I have not been involved when 1.6 development started early this year.

I just pushed a fix. Please re-pull the repo and re-run the installer.

[jms]

@Sebastian-Roth Yes your fix does indeed resolve the issue for me – thank you sir !!!