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

@ben.walker

Yep.

Look at this for installing the Trunk version: https://wiki.fogproject.org/wiki/index.php/SVN

@Tom-Elliott said:

What finally fixed it?

Are you using the “fog” user or the admin or the administrator?

@Tom-Elliott said:

What finally fixed it?

Are you using the “fog” user or the admin or the administrator?

Finally ftp://IP/images is OK without anymore configuration, it’s seem to be a native setting in Qnap.

He modify his storage node configuration too.

Thank you, I am not sure my first image was 433Gig and my second was 45Gig. I did nothing different. I am glad to see the file size has decreased.

Ben

Thank you!