Unable to locate image store during image deployment

[darbizzle]

After updating FOG from version 1.5.9 to 1.5.9.114 I have been receiving the following error pictured below:

I believe this is due to an issue where images are stored temporarily in the /images/dev directory before being moved to the /images directory upon completion. It looks like the images that are being created are not being moved to the /images directory such that when an image is being deployed the system is returning this error.

I’m a bit of a Linux n00b but is there a common way of resolving this issue? I’m thinking it might have something to do with permissions, but I don’t know why that would have changed after updating the application.

[Tom Elliott]

@darbizzle Why did you update to 1.5.9.114? We’re at 1.5.10.1673 on the stable branch

That said, I don’t think this is that, as it’s failing to actually prepare the partition.

I suspect its because the init you’re using is MUCH newer than the version of FOG you’re using. So maybe variables and tests are missing.

[darbizzle]

@Tom-Elliott We updated our FOG application because it was failing to connect to the NIC in the newer Dell QCM1250 PCs. It now successfully connects and captures an image, however it fails to redeploy to another workstation, citing a failure to locate the image store.

The directory in Linux does show an image captured in the /images/dev location, but the respective location in /images for the captured images still shows 0KB which suggests that it’s failing to move the captured image to the correct location.

[Tom Elliott]

@darbizzle The /images/dev/<mac> is the image, so as long as you are certain that’s the one it should be, you can move it from /images/dev to /images as the image path name as defined, likely /images/PDMDTRuggedWIN11DB9-2-25

I think that’s a good starting point, I was just pointing out (due to having not seen the ‘image store error message in plain print - if i’m being a slight bit honest’, but the update to 1.5.9.114 vs 1.5.10.1673 is odd to me. 1.5.9 is very very old. Updating to the latest may not have fixed the problem, but it’s always better to at least be up to date so what we’re seeing is all in line.

[darbizzle]

I’m a little sheepish to admit that I received version 1.5.9.114 not by choice, but because that’s the version I received when I updated FOG by following the instructions found here: https://www.ceos3c.com/linux/update-fog-server-to-newest-version/

I believe I can move that file to the correct location and I’m sure it would work, but I don’t think it would solve the issue of why that behavior is occurring in the first place. Is there a reason why I would see this behavior after the update? Did I miss a step somewhere?

Thanks in advance for your help, truly.

[darbizzle]

I’m realizing that the link that I referenced is no longer working, and who.is indicates that they might’ve let their domain lapse in August :-/. Here’s an archived link from the Wayback Machine that might help for reference: https://web.archive.org/web/20250430035750/https://www.ceos3c.com/linux/update-fog-server-to-newest-version/

[darbizzle]

Hey @Tom-Elliott I was able to get our FOG instance working by following the upgrade path to upgrade fully to 1.5.10.1673. I guess I should have tried that first :-/.

Thanks for your help.