@Timo

Did you reset the encryption data on the specific host? If not give it a try and report back.

@Lenain

/opt/fog/log/servicemaster.log
/opt/fog/log/fogscheduler.log
/var/log/apache/error.log

@Wayne-Workman I tried some scenarios (lots). With different number of max clients and different number of clients which get a deploy. See spreadsheet for details.

0_1455537297048_fog_testing.xlsx

Problem manually solved.
I also had a generated password with a “/”. When I tried to deploy a snapin, it failed with the same error @Hanz described.
A login with an an ftp-client redirected me into the users home directory. I changed “/” into a different character (passwd and GUI) and the ftp-client redirected me into /opt/fog/snapins.
Snapins now work without an error!

@theWizard try removing special characters and try again.

@Sebastian-Roth

Server

• FOG Version: RC-12 (42)
• OS: Ubuntu 14.04

Client

• Service Version: 0.11.5
• OS: Win 7

I am having the same problem. Can wake-up the clients in the console using wakeonlan *MAC*. When trying to wake-up a client or group in FOG GUI it creates the following error in the apache error.log

[Tue Oct 04 10:08:18.989990 2016] [:error] [pid 9838] [client x.x.x.x:35286] PHP Fatal error:  Uncaught Error: Access to undeclared static property: WakeOnLan::$_port in /var/www/fog/lib/fog/wakeonlan.class.php:70\nStack trace:\n#0 /var/www/fog/lib/fog/fogpage.class.php(1316): WakeOnLan->send()\n#1 /var/www/fog/lib/fog/fogpagemanager.class.php(230): FOGPage->wakeEmUp()\n#2 /var/www/fog/management/index.php(25): FOGPageManager->render()\n#3 {main}\n  thrown in /var/www/fog/lib/fog/wakeonlan.class.php on line 70

@Wayne-Workman first of all I am very thankful.

I am using FOG now for six-seven years. It’s a wonderful piece of software. Sure I want to help make FOG better. Thats why I am testing all these different configurations.

My only problem is that the imaging now takes twice the time.
I can handle this but I think a correct splitting would be great for the whole community.

Seems like the last client inside a group or inside the URL wakes up.

@Tom-Elliott
Running RC-12 Version 46
Tested URL with different MAC Addresses and different number of clients. We also changed the order of addresses.
Everytime we execute the URL, the last MAC in the row wakes up

@Wayne-Workman
We have different size of groups. Now we tested a group with two clients and the second client in the group woke up. First one still off.

@Wayne-Workman said:
I am working with the location plugin now. The splitting works fine.

@Tom-Elliott

switched to RC-14.

We tested the URL (also changed order) and the group wake-up directly in FOG. Each test was realized with three clients.
All clients woke-up! Great work @Tom-Elliott and @Wayne-Workman.

Thanks a lot!

@Sebastian-Roth

We are back on track!
Here a snapshot with dev-branch kernel and the new init_partclone_0.3.13.xz files. The image we are deploying was previosly captured with dev kernel an dev init.xz.

At the moment we are also running a multicast with around 12Gb/min - 13GB/min. Maybe everything has even become a little faster.

Again great support and excellent work! Thank you guys! If there are further tests let us know.

@Sebastian-Roth

That is correct.

@george1421

We are still using FOG Server dev-branch 1.5.7.112.

All binaries (1.5.3 up to 1.5.7) used the partclone version 0.2.89. Maybe thats the problem? The binaries from dev-branch where running on partclone 0.3.12.

@Sebastian-Roth

We are running several tests at the moment. Only using the Binaries which can be downloaded from https://fogproject.org/binaries1.5.x.zip.
FOG running dev-branch 1.5.7.112

Here are some results.

Binaries 1.5.7: deploy speed around 12GB/min. bzImage-1.5.7: Linux kernel x86 boot executable bzImage, version 4.19.48 (jenkins-agent@Tollana) #1 SMP Sun Jul 14 13:08:14 CDT , RO-rootFS, swap_dev 0x7, Normal VGA

Binaries 1.5.6: deploy speed around 12GB/min. bzImage-1.5.6: Linux kernel x86 boot executable bzImage, version 4.19.36 (jenkins-agent@Tollana) #1 SMP Sun Apr 28 18:10:07 CDT , RO-rootFS, swap_dev 0x7, Normal VGA

Binaries 1.5.5: deploy speed around 12GB/min. bzImage-1.5.5: Linux kernel x86 boot executable bzImage, version 4.19.1 (sebastian@Tollana) #1 SMP Fri Feb 22 01:04:27 CST 2019, RO-rootFS, swap_dev 0x8, Normal VGA

Binaries 1.5.4: deploy speed around 12GB/min. bzImage-1.5.4: Linux kernel x86 boot executable bzImage, version 4.16.6 (builder@4c3c12e8cfd6) #4 SMP Wed May 9 22:08:36 UTC 201, RO-rootFS, swap_dev 0x7, Normal VGA

Binaries 1.5.3: deploy speed around 12GB/min. bzImage-1.5.3: Linux kernel x86 boot executable bzImage, version 4.15.2 (builder@c38bc0acaeb4) #5 SMP Tue Feb 13 18:30:08 UTC 20, RO-rootFS, swap_dev 0x7, Normal VGA

@Sebastian-Roth
We did two re-captures now. One with 1.5.3 binaries and one with current binaries from dev-branch 1.5.7.112.

We have no improvments in deploying with 1.5.7. The speed of the binaries 1.5.7.112 is around 5 GB/min.
Luckily the binaries 1.5.3 boost up to 13 GB/min. Thats the speed we had before.

For now we will stick to 1.5.3 binaries running behind FOG 1.5.7.112.
If there are improvments please let us know so we can test them.

@Sebastian-Roth @Quazz @george1421
We only have computers with the following specs:

• Dell 9010 (BIOS A30)
• i7-3770
• 16GB RAM
• Samsung SSD 860 EVO 500GB

Made ten iperf3 tests in a row and got an average of 9.7 retries. Is that really so bad?

We also checked the binaries from 1.5.3 to 1.5.6. with the old image and recieved the following error:
read image_hdr device_size error

Now we are capturing a new image with the 1.5.3 binaries. The above error may have something to do with a mismatching partclone version. Hopefully the deploy speed will be at 12GB/min. If so we will try to capture an image with the current binaries.

@Sebastian-Roth

Linux debian 5.3.0-1-amd64 #1 SMP Debian 5.3.7-1 (2019-10-19) x86_64 GNU/Linux

@Quazz said in Slowdown Unicast and Multicast after upgrading FOG Server:

I vaguely recalled someone having this problem before with similar outcomes.
Linking here for further reference: https://forums.fogproject.org/topic/13733/hp-elitebook-830-gen-6-issues-capturing-images-and-deploying-images/10

Tried the bzImage529 and checked if RAMDISK size is correct.

Also tried the following Kernels which all end up with a KERNEL PANIC:
4.13.4, 4.11.1, 4.10.1, 4.9.11 and 4.8.11

Other kernels starting with 4.15.2 and above seem to work but not with the sufficient speed.

@Quazz said in Slowdown Unicast and Multicast after upgrading FOG Server:

Are you on the dev-branch

Yes I am on the dev-branch 1.5.7.109 (bzImage Version: 4.19.101)

@Sebastian-Roth @Quazz @george1421

I have some good and bad news.

First the good ones:

I created a deploy using the FOG.Wiki https://wiki.fogproject.org/wiki/index.php/Debug_Mode#Win_7
Therefor I booted a Clonezilla (2.6.4-10-amd64) Flashdrive and mounted the NFS-Share from FOG Server.

I started the deploy with the following command:

cat /images/IMAGEPATH/d1p2.img | zstd -d | sudo partclone.restore -O /dev/sda2 -N -f -i

Tried a deploy with the fog client and still one-third of the expected speed.
I think there is something wrong in the deploy process.
Main difference I can see is that the FOS uses Partclone 0.3.12 and Clonezilla 0.3.13.