Topics created by Joseph Hales

Or something more elaborate than a green dot…

This is fixed in 3406.

[quote=“Joseph Hales, post: 47440, member: 18131”]Maybe adding a hash check to the troubleshooting script? Were we going to include the updated troubleshooting script in the utils folder for SVN.[/quote]

Now that’s a winner. Let ya know if your FOG files are busted or not.

Ok updated to SVN 3348 still seeing the resize issue it is still intermittent and may or may not affect the same machine twice in a row. I ran a debug task on one that failed and manually ran the resize command as you can see in the pic attached the command not so much fails as sees the partition as already ok even though its still at the deployed size.

[url=“/_imported_xf_attachments/1/1956_2015-05-04 08.24.04.jpg?:”]2015-05-04 08.24.04.jpg[/url]

Sounds like a great feature request.

Simple enough to add. SVN 3285 released with all of this.

Hazza!!!

Wearing my idiot hat this morning just used to seeing it all on one screen like in the add snapin screen. Off to get more caffeine.

Looks like installing the SVN the first time when it added MySQL Connection Type: MYSQLI_ASYNC to the .fogsettings it corrupted the entry for sqluser placing the local host in that place and losing a semicolon. Fixing that and restarting sql fixed it. This is the threads that lead me to it [url]http://community.spiceworks.com/topic/564935-fog-database-error[/url] and [url]http://fogproject.org/forum/threads/fog-is-inoperable-after-server-reboot.11460/[/url]

I will see if I can look into adding such a feature this weekend.

Wayne, it’s much simpler to just add a schema to specify a “timeout” and if the task creation time and state are not set at that point, have it cancel the task.

Ok waited till everyone was done imaging today and ran it and no change so I went back to the forums and truncate table snapinJobs; truncate table snapinTasks; which solved the issue.

Also, please try upgrading

For future readers: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

if you’re not in the working copy directly, or explicitly telling it where the “working copy” is, it assumes the CWD.

For example:

You have terminal-ed in to: /root or /home/jhales

If you run svn up from here, but the working copy is in /root/svn or /home/jhales/svn it will give the error:

[code][jhales@localhost ~] $ svn up
svn: warning: ‘.’ is not a working copy
[/code]

if you cd into the proper directory as such:
[code][jhales@localhost ~] $ cd svn
[jhales@localhost ~/svn] $ svn up[/code]

You shouldn’t have any issues.

Or explicitly set the “working directory”
[code][jhales@localhost ~] $ svn up svn[/code]

You shouldn’t have any issues.

Update we have a PRTG server running on the same network I’m working with its admin to get it to monitor via SNMP still troubleshooting that as for network from the server switch it connects direct to out 10ge backbone and from there to our fiber ring to the individual schools I have it set for 20 simultaneous connections depending on the results of the monitoring I may increase that significantly we image at 25 separate campuses so its used pretty much non stop.

Thank you that fixed it also needed to open port 80 in ufw. Should I disable UFW completely or just open individual ports and if so is the command simply ufw disable?

i have a suggestion that will make it so that you don’t need an isolated network for testing. what i do is redirect the boot.php requests for my test clients to my test server in the default.ipxe of my production fog server file, like so:
[CODE]#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch i386
params
param mac0 ${net0/mac}
param arch ${arch}
param product ${product}
param manufacturer ${product}
param ipxever ${version}
param filename ${filename}
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme

:bootme

redirected to dev server for test environments

##test-3020 optiplex 3020
iseq ${serial} F8HLK02 && chain http://<dev-server-ip-address>/fog/service/ipxe/boot.php##params ||
##testing VM
iseq ${net0/mac} 00:0c:29:ce:74:46 && chain http://<dev-server-ip-address>/fog/service/ipxe/boot.php##params ||

normal fog server

chain http://<normal-server-ip-address>/fog/service/ipxe/boot.php##params
[/CODE]

Can you hit me up on Google

Fixed Tom teamviewered in and edited the database to remove the orphaned task. Side note if you have existing snapins remember to add them to a storage group before attempting to update them.