@maxcarpone That output was exactly what I needed — thank you for running it, and for the screenshot of the failing deployment, which turned out to be the most useful thing in the thread.
Your database is fine and your schema is current. schemaVersion 286 is the right number for 1.5.10.2402; 287 only landed this morning. And your first query returning an empty set means you have no stuck tasks at all — nothing in Queued or In Progress. The blank entries you’ve been seeing are all in Complete and Cancelled, and they’re just history: 300 of those rows point at hosts and 459 at images that were deleted at some point over the nine years that table has been filling up. Nothing is wrong with them, they simply have nothing left to show.
The real bug is the one in your deployment screenshot, and it is not your FTP password. Here is what was happening:
* Task Complete * Updating Database.....................Failed * Error returned: Failed to update imaging log * Reattempting to update database.......Failed * Error returned: No Active Task found for Host: VM-W11-TESTOnly that first error is real. FOG looks up the open imaging-log row to close it by asking for the row whose finish time is empty, and a change earlier in the 1.5.10 line moved “empty” from a zero date to a real NULL. The query FOG was building for that could never match a NULL — so on every single deployment, on every install, it failed to find the row it had just created minutes earlier. It then reported “Failed to update imaging log” after it had already marked the task Complete, which is why every retry after that came back “No Active Task found for Host” and the machine sat there rebooting into an error.
That also explains your very first post: “the host is well imaged but it is not updated in FOG, information about the last image isn’t written in the database.” It wasn’t. The imaging log never closed, the task was already marked Complete, and nothing recorded that the image had landed.
I’ve reproduced it end to end and fixed it, along with three other ways a task could end up pointing at nothing: https://github.com/FOGProject/fogproject/pull/1391
Two things still outstanding on your side:
The two MariaDB instances are worth sorting out on their own. I don’t think they caused the above, but two servers on one box is a real problem waiting to happen and it makes everything harder to diagnose. systemctl list-units 'maria*' 'mysql*' and ss -lntp | grep -E '3306|mysql' will show what’s actually listening, and sudo mariadb -u root fog -e "SELECT COUNT(*) FROM tasks" compared against the count in the web UI will tell you whether FOG and your shell are looking at the same database.
“Invalid Login” on register-with-immediate-deploy I have not explained yet, and I’d like to. It’s suspicious that a brand new user worked and fog didn’t, because that rules out the typing. Two questions: does the fog user’s password contain any accented or punctuation characters, and can you log into the web UI as fog right now with that same password? If the answer to the second is yes, the problem is in how the password survives the trip from the boot menu, and that’s a different fix from the one above.