Failing to Update Database after capture of image is complete on the client

[tgidwani]

This post is deleted!

[Sebastian Roth]

@tgidwani Ok, lets try to focus on the following warning in the logs: ftp_put(/images/dev/ac1f6bb0690e): failed to open stream: No such file or directory

What FOG does is it boots the FOS (FOG operating system) on the clients and mounts /images/dev directory (NFS export) to write the new captured image into /images/dev/<MAC-ADDRESS> - in your case the client MAC should be AC:1F:6B:B0:69:0E - please double check just to make sure there is no culprit in this. Now after the image capture is finished FOS calls back to the FOG server and tells it to move that newly captured image from /images/dev/<MAC-ADDRESS> to /images/<IMAGE-NAME> and this is exactly the point where things seem to fail for you.

Thinks to check:

• When capturing an image, do you see files being written to /images/dev/ac1f6bb0690e -> if not we need to figure out why!!
• When the capture is finished, do you still have those files in place? They should still be there if rename/move failed. -> Then try to rename/move those manually via FTP to hopefully see why it fails. Connect via FTP as below and run: rename /images/dev/ac1f6bb0690e /images/Imagename

[tgidwani]

@Sebastian-Roth When I was experiencing said error the intermediary directory was never being created.

It is working now. As mentioned in my previous reply asking about the default gateway, I think it has something to do with the Gateway configured in my network interface’s configuration file.

Within the config file, GATEWAY= was pointing to an IP address that was not assigned to any machine on the current network when I moved networks. When I removed the GATEWAY= line from the config and ifdown and ifup my network interface, the update database error was resolved.

Does FOS when communicating with the FOG server go through the default gateway even when both the client running FOS and the FOG server are on the same network?

[Sebastian Roth]

@tgidwani Wow. Really glad you figured that out. I have done a lot of networking but I wouldn’t have expected the gateway setting to cause such an error. In theory the gateway information is only ever used when the host tries to connect to a machine that is not within it’s own subnet. So gateway shouldn’t play a role here as long as both were in the same subnet.

Are you able to replicate the issue when putting the GATEWAY= line back into the config??