I just wanted to drop a dedicated thread wanting to thank everybody on the FOG Team for all of the hard work/development on FOG itself and for the fast and helpful technical support on the various topics around the forums!
Seriously guys, this is an impressive team here! Thank you ALL very much for all of the time, support and effort you’ve put into this project! I think I speak for a lot of people here when I say that it’s all “very much appreciated!”
So today, I updated the bzimage and init.xz files individually and tried to register a host and presto! It worked!
Once again, thank you everyone on the FOG Project team for your support and hard work on this project!
I just wanted to drop a dedicated thread wanting to thank everybody on the FOG Team for all of the hard work/development on FOG itself and for the fast and helpful technical support on the various topics around the forums!
Seriously guys, this is an impressive team here! Thank you ALL very much for all of the time, support and effort you’ve put into this project! I think I speak for a lot of people here when I say that it’s all “very much appreciated!”
@Wayne - I just tested out using snp.efi and that solution seems to have worked! I am uploading an image of our surface pro 3 as I write this.
I too, have a related issue with our Surface Pro 3. I was able to successfully register the host, but when I actually wanted to upload an image of my surface pro 3, it failed on the following part:
Mounting File System…failed.
I ran the “touch” commands on my storage location and checked my /etc/exports file. Everything is in order. Also, I tried uploading an image from a regular HP Desktop (Windows 7) and was successful (using the undionly.kpxe).
But when I switched it over to ipxe.efi for my surface pro 3, again, I can register and attach an upload task to it, but it’ll eventually fail again on the “Mounting File System” part…
Any advice would be appreciated.
EDIT: I’m running FOG SVN 3537
Possible? Yes. Practical? Not really, since we have quite a few legacy models.
What I think I might do though is leave our old FOG 0.32 server running in case we need to use it for these specific legacy images.
Thanks again to everyone on the FOG team for all of the development and support you all do!
So as some of you know, I’ve had some issues with FOG lately that I’ve mostly resolved by reformatting my Ubuntu FOG server and by reinstalling everything fresh. With that being said, I am now able to successfully upload and deploy new images to my FOG server.
BUT, I too, have this exact same issue reported on this thread on SVN 3537. It seems to ‘only’ occur with these legacy image settings:
Image Type: Single Disk - Resizable
Image Manager: PartImage
PS: We still use the settings listed above for some legacy XP machines that were imaged that way. All other legacy “PartImage” images that are “Multi-partition - Single Disk” work just fine.
I created a post with this same error last week and could not figure out the solution. (still appreciate the help none-the-less to those who tried).
https://forums.fogproject.org/topic/5134/svn-3513-unable-to-locate-image-storage
Anyways, I have, since then, totally rebuilt my FOG server and reimaged it using Ubuntu 12.04 LTS (64-bit) and I’ve ran all of the system updates for it. I have installed the regular FOG 1.2 stable and everything works great with registering hosts, but I still get the very same error as mentioned in this thread when trying to image a host…“Unable to Locate Image Store”.
I have tried to run the following rpcbind commands mentioned in this thread, but all I get is an “unrecognized service” error…would appreciate any help.
Thanks
One more quick update before the weekend…
So after the image upload took place on SVN 3513, I tried to deploy it back down, but it was unsuccessful because when I tried to assign the deployment task, I received the following error:
Failed to create deployment tasking for the following hosts
You must first upload an image to create a download task
I went and checked out the /images/dev folder and I found the image upload was stuck in there with its mac address. Any insight?
We did have a couple of images that we uploaded on FOG 1.2, so I went ahead and tried to deploy one of them on this new SVN 3513 and I received the same “Unable to Locate Image Store” error…
On another note, it seems that I “am” able to upload an image. Once I upload a new image, I will deploy it back down for testing purposes.
BUT I really can’t afford the time to have to re-upload all of those images individually… 
PS: I will plan to try to reinstall FOG using the latest SVN version on Monday once more. If it comes down to it, I may just remove FOG and retry all of this from scratch if nobody can figure this out. If I do decide to uninstall FOG, should I use these instructions found here? https://wiki.fogproject.org/wiki/index.php/Uninstall_FOG
@Wayne - No, unfortunately, this is not resolved yet. The picture of all of my images mostly consist of images created back with FOG 0.32. I have tried two different images/machines and I get the same “Unable to Locate Image Store” or “Unable to Locate MBR”.
I have yet to test anything out with uploading a brand new image. But never-the-less, I would like to tried to resolve this issue with the older “PartImage” images.
Here’s another picture of the images directory on my Ubuntu FOG Server. The one image I want to currently use is selected within the screenshot. Since these are older XP images, they were uploaded using “Single Disk - Resizable” instead of using “Multiple Partition Image - Single Disk”.
PS: We no longer use “Single Disk - Resizable” going forward…but some of our older images/models still use it.
