Posts made by Mark Buteyn

Also for what it’s worth, the same error message shows up on everyone in line. So the Waiting on X other clients always has zero for the value no matter how many in line.

scratch the deploy slots comment. I played with some settings and it is working. Still get this error message though.

When deploying images to multiple computers from storage nodes I get an uncaught exception error if there are other image deploys in progress. It also seems to limit me to one deploy at a time. I have available deploy slots. Attached is a pic of the error.

After the deploys to other computers finish, it continues on just as it did previously.

For what it’s worth, when updating, sometimes that step times out and sometimes it doesn’t. It seems to be an internet connectivity issue on either my end or the other end. I had this when updating to 5592

@Tom-Elliott Thanks Tom. Just pulled and installed and it’s working for me too.

When creating a new image in Image Management on the latest SVN, if I choose a different Storage Group and submit the form, the Storage Group selection doesn’t reflect on the image definition. It switches to default storage group. If I upload to that image it also uses the default storage group.

Currently, I am only seeing notifications from the fog client if I am logged in as an administrator level user. So scheduled shutdowns just shut the computer off if a standard user is logged in. Is this a misconfiguration on my part? I’m running client 0.9.5 and server version 5124

@Tom-Elliott Thanks for all your work on fog. Long time user. I’m on 5124 and CPU utilization looks good. I echo @Trevelyan 's concern about the user tracker report. CPU utilization goes high and then comes back down after the 500 error is sent to the browser. I know you said you’d fix it when you got to work. Is there a way for me to find out what version fixes it? Then I won’t bother posting this question in the forum.

Thanks,

Mark

https://forums.fogproject.org/topic/5398/upgraded-ubuntu-from-13-04-to-14-04-now-web-console-will-not-come-up

This helped me. I changed the bind-address from my IP to 0.0.0.0

Significantly less secure I think, but it worked.

I was on 3396. Looked it up in my records.

I just pulled via git and am running the install script. At the upgrade database step I refresh my fog host and click the button to do the schema update. After that I get a blank page. Apache.error shows a lot of couldn’t fect mysqli in …Mysql.class.php on line 63 preceeded by two HY000/2002 errors.

My understanding is that this means that it’s not connecting to the database. Any pointers on this one?

This was an upgrade from a previous svn ~3300 or so…

I fully understand that documentation is a huge time sink! I hope I can help.

I renabled fog on the client and deleted everything from the master. It did not remove the tasks even after a service restart.

I’m creating a batch file with this command:
schtasks /delete /tn fog\20@0@s /F
This deletes the task scheduler items. The 20@0@s is how the name of the tasks that are created show up.

Yes, new as in beta. Glad to know that this is a known issue. Also glad to know that these things are set in task scheduler. Is there documentation for the new version that I should be reading somewhere? Or documentation that I can contribute to?

Green fog wasn’t working with the legacy client and the 3396, so I deployed (without testing first) the new client and got myself in trouble… Lesson learned when I want to be on the bleeding edge! The log in the legacy said something like “validating green fog tasks. 0 tasks validated”

New as of the 3396 build. Is there a newer one out?

Am I reporting this in the proper forum?

I disabled greenfog for most of my clients. and set the shutdown time to later to not affect others. It seems that the settings held after a reboot even the the fog.log shows that greenfog is disabled on the client. I’m verifying that this is the case and not just user error.

I installed the Fog Client that is part of the 3396 build on Windows 7 Pro both 32 bit and 64 bit. The Green fog portion of the client is shutting computers down while users are logged in and working. It also shuts down locked computers.

Any hints? I’ve disabled it for now.

Debian 7.8 on a VM with one Xeon 2.66 processor and 1GB of memory assigned. (Is that to little of resources?)
FOG 3396 release.
I was running .32 and didn’t run into resource issues, but bigger and better functionality often requires more resources.

I typically image a lab of 30 machines at a time. If I’m watching their progress on Active Tasks the master’s CPU utilization goes to about 80%. As soon as I pause it, it drops to about 8%. I don’t send images from the master, only my two storage nodes, I let the master handle all the management stuff.

How can I help troubleshoot this or is this expected?

I just decided to make the one that is working the master. The other two will still accept images and deploy them.

I’m not good at debugging init scripts. It seems that the init script claims a PID, but the PID never shows up in top on the ones that aren’t working. This is also evidenced when I do a stop of the FOGImageReplicator script, I get an error that says can’t kill PID 3325 (or whatever the PID is). If I do a stop again it says OK. So something isn’t firing right, but it’s not that big of a deal to me since one is working.

Thanks for all your work on this. Much improved over the last 6th months.

OK, thanks.

Yes they have worked in the past. And I can still pull images from them, it’s just that replication isn’t working.

Thanks for your help.

Wayne: Would you recommend I blow away the storage nodes and start with 1.2.0 then go to 3396? I’m assuming you mean the storage node passwords, not the mysql passwords. I didn’t change any passwords, but maybe the huge jumps caused issues with the password

Junkhacker: They are all on 3396, all debian 7.8. The DefaultMember and primary Storage Node are VMs. my replicated storage nodes are physical machines. None of the storage nodes start the script successfully only the DefaultMember.

I just updated from .32 to 3389 (I think that was the version, it’s also the port number for RDP, so I may be wrong)
I use Debian 7.8 currently. After the update the FOGImageReplicator wouldn’t start on the DefaultMember or any storage nodes. Updated to 3396 after via git on all machines and re-ran ./installfog.sh. The Defaultmember now runs FOGImageReplicator but none of the storage nodes do. The helpful error message after running “service FOGImageReplicator start” is “failed!”. I can’t find why in the logs I’ve been looking in. Any hints?

Turns out the problem is with the dc7900 and ipxe. It looks like according to [url]http://www.fogproject.org/wiki/index.php/WorkingDevices[/url] page that there is a known problem with the dc7900. We have a high percentage of those around here yet, so I’m just going to back rev to .32 until I can get the ipxe thing figured out on the dc7900. The other site had dc5800s and Optiplex980s which both worked fine with 1.2.0 I was able to get the 800 G1 to go fine with the 3.8.8 kernel.