Topics created by dolf

@Sebastian-Roth https://github.com/FOGProject/fogproject/commit/d3a70dd417eb1d08b48a637e26ec8776f4409d29

652b6f04-876c-4c27-89b0-d3bc6b01513e-image.png

I commented out the “style” info you put, and moved it to push info out to the left instead of the right so that the form field is still accessible when reading the information.

@Wayne-Workman That worked! Thanks!

@dolf The one marked as the answer. We keep the FOG Client article updated, because it’s important.

@Tom-Elliott said in Page timeout when creating multicast task:

This, for now, does mean multicast from groups will not generate the requisite snapin taskings, but it’s only because I need to think of the logic to enable it. It should work hopefully soon.

I’ve been learning about triggers in mysql. It’s really super efficient, you could do all the snapin stuff from deployment with triggers.

@Tom-Elliott you genius

Yes, I was copying files which I captured manually. Your three suggestions, to

temporarily disable replication, not create the image definition,
or use the dev folder

all work, and I’m not sure why I didn’t think of that… #facepalm

@dolf Sounds really strange to me! I’d suggest doing the reverse test. Pop that HDD back into the other PC and see what WOL is doing?!?

I’m pretty sure it does fall on the installer already.

I’ll double check just to be sure:

1 configureSnapins() { 2 dots "Setting up FOG Snapins" 3 mkdir -p $snapindir >>$workingdir/error_logs/fog_error_${version}.log 2>&1 4 if [[ -d $snapindir ]]; then 5 chmod -R 775 $snapindir 6 chown -R fog:$apacheuser $snapindir 7 fi 8 errorStat $? 9 }

That’s the script portion in the installer’s functions.sh file.

I see what’s wrong now. Thanks for leading me to it. Yes, Servers were getting the information set, but plain nodes were not. Should be fixed in latest. Thanks for reporting. Also fixed a few minor issues while I was there.

@dolf Simple doesn’t get the job done when you’re trying to measure bufferbloat, or other multi-variable problems 😉

Check out Flent: https://flent.org/

This is solved as the version is now operational again, though Sourceforge is still DITW (Dead in the water) at this point.

If the CloneZilla image is not compressed, it will not have the .gz extention (easy to check for), and the last command becomes:

cat /home/user/czimg/sda2.ntfs-ptcl-img.* | pigz -stdout > /images/fogimg/d1p2.img

If CloneZilla was invoked using dd, we can concatenate and pipe to partclone:

cat /home/user/czimg/sda2.ntfs-dd-img.* | partclone.$fstype -fsck-src-part -c -s - -O - | pigz -c > /images/fogimg/d1p2.img

etc… There might be a few more cases to consider.

See this example: https://forums.fogproject.org/uploads/files/1468447170744-gparted_details_bad.htm

Thank you for looking at this issue! I will try out the new code and report back.

I’m on Ubuntu 14.04 though…
Anyway, it’s working with php5.

I’m solving for now as I’m fairly sure this is fixed. Of course feel free to test and update this thread as any other information comes forward. I’ve tried to test, but too many other things going on at the moment.

Ok thanks for letting us know. So I guess we are save to solve this now.

@Tom-Elliott I sent you a msg as well, the error I posted is no longer present after cleaning mutlicast “stuff” from fog server and rebooting, but now I get to partclone screen and it hangs.

Multicast log from gui

[02-03-16 9:30:29 am] | Task (17) Multi-Cast Task is already running PID 2461 [02-03-16 9:30:39 am] | 0 tasks to be cleaned

Service Master log

[02-03-16 9:26:47 am] service_signal_handler (30080) exiting. [02-03-16 9:26:48 am] service_signal_handler (29843) received signal 2. [02-03-16 9:26:48 am] service_signal_handler (29843) killing child (29861). [02-03-16 9:26:48 am] service_signal_handler (29843) exiting. [02-03-16 9:27:58 am] FOGImageReplicator Start [02-03-16 9:27:58 am] FOGMulticastManager Start [02-03-16 9:27:58 am] FOGImageReplicator Start [02-03-16 9:27:58 am] FOGTaskScheduler Start [02-03-16 9:27:58 am] FOGPingHosts Start [02-03-16 9:27:58 am] FOGImageReplicator fork()ed child process (1356). [02-03-16 9:27:58 am] FOGMulticastManager fork()ed child process (1357). [02-03-16 9:27:58 am] FOGImageReplicator fork()ed child process (1355). [02-03-16 9:27:58 am] FOGImageReplicator child process (1356) is running. [02-03-16 9:27:58 am] FOGImageReplicator child process (1355) is running. [02-03-16 9:27:58 am] FOGTaskScheduler child process (1354) is running. [02-03-16 9:27:58 am] FOGPingHosts fork()ed child process (1358). [02-03-16 9:27:58 am] FOGTaskScheduler fork()ed child process (1354). [02-03-16 9:27:58 am] FOGPingHosts child process (1358) is running. [02-03-16 9:27:58 am] FOGMulticastManager child process (1357) is running.

I rebooted between 9:26 and 9:27 as you can see from log.

This is tasked to multicast from remote storage node I might add. Have not tested multicast from server subnet yet, and I’m running trunk per the 6177.

I’d also like to add that after trying to run a multicast the server shows “This is not the master storage node” under multicast log, until I completely clean mysql of multicastAssoc, MulticastgroupAssoc, and task type=8 followed by a reboot, then I get the logs as shown above working correctly.