@nengelhardt Export your images and host list, build up a new Fedora 22 server build, install FOG trunk, and import your hosts and images, then recreate your “image definitions”. Then set your DHCP option 066 to reflect the (possibly) new IP address.

The easiest way to accomplish this is to run in parallel for a little while. Although many people don’t just have spare servers or powerful desktops laying around to dedicate to a new FOG server… But if you did, it’d be as easy as mounting the remote NFS share on the new FOG server to a temporary directory, and then copying over your images. The host export bit is just done in the web interface under Host Management. You may not even need or want to do this if you have only a few machines registered.

If you don’t have spare hardware laying around, you’ll need to connect to a remote windows share and just copy your images there (recursively). You would then later connect to that share via Fedora 22 Server and copy them back (CLI recursively).

Here is an article on the various ways to move to FOG Trunk. You don’t need any pre-existing version of fog to install FOG trunk… The article name is deceiving but it was written for the needs of the many (upgrading). https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk

@Wayne-Workman Screen Shot 2015-07-02 at 9.20.13 AM.png This is a picture of the first 2 of 113 errors I get. I can post them all but it will take a long time. lol. Also I try backing up my FOG Configs but when I get to the FOG Configuration section in FOG there is not a Configuration Save section. I see this: Screen Shot 2015-07-02 at 9.29.08 AM.png

Setup FTP and NFS on the storage array and use it directly, rather than trying to NFS into the VM and NFS out of it again.

Neat, I’ll have to give this a shot. Thank you guys.

thanks for that , i have ammended that file with the proxy details but still getting error 403

OK, ta. Probably will go FOG then for PXE boot installs, and investigate using a Linux shell script for copying images to local/SAN drives.

Question answered, just not sure how to mark it as such.

For the time being I am on 3501, once I get through the bunches of systems I have to image I will be keeping up with trunk, just don’t need anything to break right now, so staying put where I got it working.

I will just update to SVN later on and be good to go with the Kernel.

I second that emotion you guys are awesome.

@sbps As said @Wayne-Workman the solution is to used “Location Plugin” with differents “storage group” (one group per location) and use another tools to sync images between storages, because (I think) the replication is between nodes in a same group.

@MRCUR said:

I do hope when 1.3.0 launches, the old client is still supported as it is in the current SVN’s. That way I can work on removing the legacy client from existing machines and installing the new client. Otherwise it’s going to be a long time until many machines get the new client as we do not reimage all that quickly with 8,000+ hosts.

@Developers Probably something to consider there…

I, too, am partial to the legacy client… it’s a fall-back, at the least.

You go, /u/Junkhacker! I would love to have bit torrent sync, so long as it allows me to lower my overall deployment time when doing 6+ clients.

I can’t use multicast because that hurts our network in a VERY bad way (all network traffic basically halts), so I use 5 concurrent single casts typically to about 30 computers at a batch.

Thus, whatever you do, my deplying to 6-10 clients takes about 2x as long as 1 client does. If the torrent send can reduce that number for 6+ to 1.5x of 1-5 clients, then I would be extremely happy and would find great benefit for my company.

If it works as good as possible, I would expect total deployment time for 30 clients to be like 15-20% of what it currently is.

lol… so now on I’ll just say “Update to Latest Trunk”

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

I’ve already got.

Thank you so much guys!!!

I can’t say I have checked… but it’s supposed to be either fog:fog or fog:root on a standard installation.

One of the things I hate about Ubuntu, lately, is exactly this.

Ever since moving to Upstart to control services, the services seem to no longer be controlled.

It will start services before the dependent services (Networking, Local system, etc…) is running.

This breaks other things as well, such as the linux side FOG Services (FOGMulticastManager,FOGScheduler, etc…)

What’s happening, from what I can see, is it starts mysql before networking is ready. It works for a small amount of time, but then when networking is ACTUALLY ready, the service fails. Upstart is supposed to handle restarting a crashed service, but it’s almost like it was completely forgotten about.

@Tom-Elliott said:

What do you mean?

FOG Is a network booting system. The BIOS needs to be setup to allow network booting as the first option.

@ben-walker https://wiki.fogproject.org/wiki/index.php/FOGUserGuide