My guess, because of the database dump, the FOG User (on the server) password is not what your database thinks it is.

I’d edit your fog server and reset the password to whatever it was, or figure out what it currently is and update the storage node on the server.

To further help:

https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

@arnaudrigole there’s groups to individually set, and global if all systems are showing the same issues.

FTP move should not be an issue or we should see a somehow FTP related error message - which would happen much later anyway. To me it seams like the image/VM might be corrupted. Although disk space and inodes are not running out yet.

@mecsr Have you tried running chkdsk /f within the client system as suggested on the screenshot??

I really don’t hope that this is the case but could it be the server disk is failing??

Please try restarting the mysql service with this command: sudo service mysql restart and see if you can run the Database Update on the web interface directly after that.

Thanks for reporting back. Marking this solved.

@HROAdmin26 Did you get to test this again without clearScreen? Hope we can find out what’s causing this!

@ellusiontech Any news on this? Were you able to capture a packet dump using wireshark? Thanks for testing in the shell and sending a screenshot. Seams like this is NOT a spanning tree issue. But I really wonder why DHCP is fine on the first go, then downloads iPXE via TFTP and fails on the second DHCP (send by iPXE)?

@Wayne-Workman Here is what I have in the log files.

[Mon Feb 08 03:20:01.348426 2016] [auth_digest:notice] [pid 951] AH01757: generating secret for digest authentication …
[Mon Feb 08 03:20:01.349152 2016] [lbmethod_heartbeat:notice] [pid 951] AH02282: No slotmem from mod_heartmonitor
[Mon Feb 08 03:20:01.362390 2016] [mpm_prefork:notice] [pid 951] AH00163: Apache/2.4.16 (Fedora) PHP/5.6.15 configured – resuming normal operations
[Mon Feb 08 03:20:01.362410 2016] [core:notice] [pid 951] AH00094: Command line: ‘/usr/sbin/httpd -D FOREGROUND’
[Mon Feb 08 03:20:01.364246 2016] [:warn] [pid 25148] ./mod_dnssd.c: No services found to register
[Mon Feb 08 03:20:02.367032 2016] [mpm_prefork:warn] [pid 951] AH00167: long lost child came home! (pid 25148)
[Thu Feb 11 13:56:59.606821 2016] [suexec:notice] [pid 948] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Thu Feb 11 13:56:59.691460 2016] [auth_digest:notice] [pid 948] AH01757: generating secret for digest authentication …
[Thu Feb 11 13:56:59.692369 2016] [lbmethod_heartbeat:notice] [pid 948] AH02282: No slotmem from mod_heartmonitor
[Thu Feb 11 13:57:00.881250 2016] [mpm_prefork:notice] [pid 948] AH00163: Apache/2.4.16 (Fedora) PHP/5.6.15 configured – resuming normal operations
[Thu Feb 11 13:57:00.881303 2016] [core:notice] [pid 948] AH00094: Command line: ‘/usr/sbin/httpd -D FOREGROUND’
[Thu Feb 11 13:57:01.192982 2016] [:error] [pid 1389] [client 10.50.3.21:49721] PHP Warning: mysqli::mysqli(): (HY000/2002): Connection refused in /var/www/html/fog/lib/db/MySQL.class.php on line 64

@Tom-Elliott Yes, thank you.

Regards,
Cédric

@Sebastian-Roth said:

You should never use tools like resizefs, gparted or fdisk on your system disk (sda in your case) within the running system!

I use it each time I have to extend partition on linux within the running system 😄 (I use snapshot before 😛 )

@Tom-Elliott Thank you for the quick fix.

I’ve updated the code base to urlencode the passwords and decode them once in the FTP class. I don’t know if it will fix the issue at hand, but it’s worth a shot.

@Wayne-Workman said:

Wiki has been updated about kernel updating. I made a new article because I couldn’t find anything about it.

Article is here, it is pretty sharp looking 🙂
https://wiki.fogproject.org/wiki/index.php?title=Kernel_Update

Looks GREAT!!!

@Junkhacker said:

worth noting here is that if you create a “Mobile/Quick Image Access Only” type account you can use the pxe menu for what you want but the info will not work to log into the web interface. slightly more secure since that way you’re not sending out the admin username/password as plain text to every host that pxe boots.

So using that method, they can create a new account with “Mobile/Quick image access only” and plug that user’s username and pass into the script below to make it more secure. Nice.

Amazing what I know sometimes, even if I can’t seem to do anything right today 🙂

@Tom-Elliott The work around has helped immensely. Thank you!

Let’s see MIcrosoft or countless other vendors give this kind of support.

@Sebastian-Roth said:

But what about the “Updating Database” error on the picture in your first post? Do you still see this?

No it´s work OK

@Wayne-Workman said:

@bsmaby FTP is used to move images from /images/dev to /images. If this fails then it’s likely a simple credentials mismatch. You will find your solution in the credentials area of our FTP Troubleshooting article, here: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

SOLVED: Thank you so much! It ended up being both a miss match of passwords through out fog and also the permissions for the image folder was an owner of root and I am using a fog user instead so I had to switch the permissions to make that work. Thanks!

@bsmaby

Everything is in the link Wayne posted. Specifically, https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP#Permissions and https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP#Credentials_.2F_Passwords

Let us know if you continue to run into issues.

@Sebastian-Roth I don’t have deep understanding of FOG internal works, but I can say that when option 67 was set to prelinux.0 the kernel panicked.