Capturing image update database failed

[Baessens]

@Sebastian-Roth Here you go.

[Sebastian Roth]

@Baessens Thanks for the pictures. Looking good from what I see.

Weird thing is I don’t have this problem when i capture an image in “legacy mode” on our hyper-v server.

Is this a different FOG server? I really wonder why it would say Could not create file . in one case but not in the other if this is all on the same FOG server.

Please move the temporary folders created when capturing last just to make sure:

mv /images/dev/0800270d1e06 /images/dev/0800270d1e06_old
mv /images/dev/0800275021ae /images/dev/0800275021ae_old

Do you have SELinux disabled (in case this is a CentOS server)?

[Baessens]

@Sebastian-Roth

It’s an Ubuntu server. (16.04)
I just tested it and cannot upload an image anymore at all. I have no problem deploying old images.

I also moved the temporary folders before trying to capture.

I capture on one fog-server(FOG1) then let it replicate to 3 other FOG servers which are full nodes. Then i just export and import the images list from FOG1 to the others. Maybe there’s a problem over on some other FOG server with creds, i’ll check some things.

I last uploaded an image on 25th of august, without issues.

Thanks

[Baessens]

@Sebastian-Roth

Also: the /images folder is on a different location(virtual hard drive) then the OS.
EDIT: i’m now on 1.5.9 and deleted all the storage nodes. Still same problem.

[Sebastian Roth]

@Baessens Taking another close look at the error message I found that I got the dot at the end of Could not create file. wrong. It’s not the dot marking the current directory but just a full stop at the end of the sentence.

Please grab the FTP connection settings (IP: 10.0.0.40, user: fogproject and password) from your /opt/fog/.fogsettings file, connect to your FOG server using any known FTP client program and try create directory /images/dev/0800275021ae and upload a random file to that new directory.

[Baessens]

@Sebastian-Roth Thanks for your reply.
The password in the /.fogsettings file is different then the one in the GUI under TFTP server.
Should i change the one in the GUI to match the one in /.fogsettings?

Also i can upload a random file in there.

[Baessens]

@Sebastian-Roth I can also create a directory and upload a random file into that new dir.

[Sebastian Roth]

@Baessens said in Capturing image update database failed:

The password in the /.fogsettings file is different then the one in the GUI under TFTP server.

Are the usernames different as well?? When only the password is different we should see a login error in the picture instead of a “Could not create” message I reckon.

Please go through this: https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password

[Baessens]

@Sebastian-Roth

It seems to only be the password that is different.
i’ll try that resyncing thing too.

[Baessens]

@Sebastian-Roth I am still getting the same error.
I might just install a whole new server. Can you think of anything else that might be causing the error?

Thanks for all your help allready.

[Sebastian Roth]

@Baessens Too bad. I usually try to dig into things till I find the root cause of it. Though I understand if this just seems unsolvable.

Re-reading most of the topic I saw that you seem to have a subdirectory /images/dev/dev. Though I don’t think this can cause the issue I am wondering where this came from. Please run ls -alR /images/dev/dev and post output here.

Meanwhile I am digging through the code to see what else we can try.

[Baessens]

@Sebastian-Roth
Could it have something to do with the SQL creds?

I think it must have happened after an update, either from FOG or Ubuntu.

[Sebastian Roth]

@Baessens said in Capturing image update database failed:

Could it have something to do with the SQL creds?

With SQL creds wrong you’d see completely other issues and wouldn’t even be able to schedule a task in the web UI.

I think it must have happened after an update, either from FOG or Ubuntu.

Don’t think I have ever seen this happen from an update. Possibly something you did when moving images to a differnt disk/partition.

[Sebastian Roth]

@Baessens Ohhhhhhhh no!!! Why haven’t I noticed this before??? Can’t believe it. The second picture of your initial post actually has the solution to this riddle in it already. Image is named UEFI01/09/20v2004 and as a forward slash is the directory separator on Linux systems it will fail to rename the uploaded image…

Simply use dashes (-) instead of the slash in both the image name and path and I am sure it will upload just fine.

We don’t get that very often and I actually thought we had some kind of regex check in the web UI to prevent from this but seems like I was wrong.

[Baessens]

@Sebastian-Roth Wow… Good spot! I always use a dash, but for some reason it uses / in the path.
It doesn’t show it in the images list tho, need to click on the image name to actually see it.
I think there is a regex check but only for the image name, not the path. (which is usually the same)

I’ll try it right away.

[Baessens]

Works fine now. Thanks @Sebastian-Roth !