Fixed in trunk in that it should be downloading the file properly and this has been confirmed on another thread.

@Tom-Elliott I am aware. This is fixed too, btw 🙂

I imagine this is currently working as we no longer have a save group bar being passed but the more accurate deletemulti but the fact is you should not be seeing that on a task page.

It is now. It was not when you asked. I lost this in the trap of forum posts so I appreciate the find.

It is now fixed.

@Tom-Elliott Yep, it’s there now for me as well.

I get the location request and I hit ? and it just loops back to asking again and again. I know the numbers and can hit 7 or 8 which are the DB number assigned to my locations but they never show up on the menu when requested.

I’ve change the code that downloads the client, kernels, and inits. I 'm not going to background it any more as this might be the cause of a partial download. When the script exits, it kills the other backgrounded tasks.

This was fixed last night, sorry I didn’t update sooner and as always thanks for the report.

You can delete them now. Please update and thanks for reporting.

@Wayne-Workman Partially solved…

0_1447746331223_upload-04a3ae86-3b52-4d55-9616-b60f93f3740a

I’ve decided to resolve the thread as the limiter IS in fact working. And most people, you’re right, will only be replicating one image or another.

So I guess we can mark this solved for now!?

Don’t know if you fixed another issue yet or not but,

During the full registration process while network booting, on svn 4338 cloud 5323,

We had two locations created but only one option showed up for us to choose in the ? listing.

May or may not be relevant, we noticed as of a few revisions ago that imaging things based on location would try to pull the image from the wrong location. Uninstalling the plugin sort of worked, but left behind the Location column in the hosts view which listed them all as a location variable. Trying to re-install it gave similar results as trying to install it on a fresh install. (failed oddly)

I can’t be more specific on what SVN this started with, sorry. We jumped up 2-300 on the Cloud counter last week, and I’ve pulled down SVN more than once in the last few days as commits have been made (i watch the activity log like a hawk). I apologize for my lack of concrete data to report here.

@Tom-Elliott said:

I’ve removed the dirname function from the stuff, if you can update and let me know if things are good?

Yes it’s ok now

Thank you

@Jbob said:

@Claude-Girard v0.9.6 is released, and this includes the snapin fix for the problem you originally posted on. (https://news.fogproject.org/client-v0-9-6/ )

Thank you.
I just tested and for me it’s ok.
You can mark this thread solved, but I will open a new one for the others problems, discussed with Tom, they are’nt solved.
And I found a snapin bug again, but not due to client.

Thanks again

That’s a great line @Wayne-Workman !
Installed without a hitch.

Both time I have installed FOG though, the password given at the end of the install doesn’t work.
Last time I looked up how to change it, after that I could log into the web interface.

Those are nothing more than the source files to what/how our inits work. They’re not installed anywhere and nothing is done with them during installation.

@Tom-Elliott said:

@technokami It uses the Storage Node queuesize as it’s the node side of it.

Ah ok, now it works. Thanks again.

That fixed it.

We have a LOT of login history here. I bumped it to 512