Capturing image update database failed
-
Hi there
FOG version: 1.5.9-RC2
I’m getting the “failed to update database…” error at the very end of capturing an image.
This problem occurs when I am trying to capture a Windows 10 UEFI (V2004) image. (see attach. below)I use Virtualbox and set my DHCP option 67 to undionly.kpxe to capture, as capturing doesn’t work when i put it on ipxe.efi. (I did this before and never had a problem)
Weird thing is I don’t have this problem when i capture an image in “legacy mode” on our hyper-v server.
I keep seeing the username “fogproject” in there, but i don’t have a user by that name tho…
Any help would be appreciated.
-
Some time ago, FOG changed the linux user to be ‘fogproject’ instead of simply ‘fog’.
This is the account the FTP tries to connect to.
Looks like it can log in successfully, but fails to move the files, indicating a permission problem.
sudo ls -lah /imagesWill show you current permissions.
More than likely the owner is incorrect.
sudo chown -R fogproject:root /images -
-
@Baessens What about the files in
/images/dev?We can assume credentials are fine; otherwise it would complain about that before being unable to create a file (I assume, could be wrong)
-
@Quazz
I do have 3 other fog servers who sync the images from this one. Maybe that plays a role somehow?What about the files in /images/dev
-
@Baessens Please post the output of the commands
mountanddf -hhere. Text output or picture will do. -
-
@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_oldDo you have SELinux disabled (in case this is a CentOS server)?
-
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
-
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. -
@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/.fogsettingsfile, connect to your FOG server using any known FTP client program and try create directory/images/dev/0800275021aeand upload a random file to that new directory. -
@Sebastian-Roth Thanks for your reply.
The password in the/.fogsettingsfile 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.
-
@Sebastian-Roth I can also create a directory and upload a random file into that new dir.
-
@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
-
It seems to only be the password that is different.
i’ll try that resyncing thing too. -
@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.
-
@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 runls -alR /images/dev/devand post output here.Meanwhile I am digging through the code to see what else we can try.
-
@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.
-
@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.
-
@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/20v2004and 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.
