Do you mean just securing the web UI with a certificate? Or do you mean securing the client communication between the server and the client with a cert? I have done the former.

@Tom-Elliott I tried some newer kernels like 5.3.3 as well as what shipped with 1.5.7 (kernel version 4.19.48). I tried using the original version of init.xz but it claimed my memory was too low or something of that nature so I switched it back. The speed didn’t seem to change at all on any of the different kernels, almost like the speed wasn’t related to those kernels. Also as another piece of information I am using UEFI pxe booting with ipxe.efi as the boot file.

I just updated to 1.5.7.115 but no change at all. Just for full disclosure.

@Tom-Elliott It is possible it is something in my environment. Typically it is a single machine (imaged either via the console, or directly from the machine itself by a member of our desktop support team). It seemed related to the version because I first noticed it after I upgraded from 1.5.7 to the dev version of 1.5.8 and then later the dev version of 1.5.7.102. It went from like 12GB/min to 4GB/min or 1GB/min. The servers are production boxes so I can’t make too many changes without potentially affecting others but it still seems like it is related to the update I did. Perhaps the update of partclone? Also I noticed that when I pulled an image today for testing, the capture was super quick at 10GB/min but the deploys to the same machine and others like it were 4GB or less. I feel like I am missing something extremely mundane and obvious.

@Sebastian-Roth They are normal SSD sata drives for the most part. I was told by a member of the desktop team today though that they tried to image an Optiplex 7070 with an M2 solid state drive (the ram style drives) and it was around 1.4gb per minute.

I will certainly try to make some changes, but the fixes that came with the dev version far outweigh the speed issues I am having at the moment. Hoping some bug fixes in the 1.5.8 version will do the trick. I will keep testing as I can. Thank you all for your help for now!

@Sebastian-Roth said in Slowness after upgrade to 1.5.7.102 (dev branch):

file /var/www/html/fog/service/ipxe/bzImage533

Good catch, found the typo and got it to deploy. The speed is the exact same however. I stepped through all the steps, verified the 5.5.3 Kernel and the speed is around 950mb per minute. Way slower than my usual. Part Clone is .3.12, I tried using the old init.xy file from 1.5.7 but it claimed I didn’t have enough memory. Very very odd. Do I just deal with it until stable version of 1.5.8 comes out maybe?

@george1421 Tried the debug method, it booted from bzImage533 but it failed to start. Below is the error I recieved while attempting to boot using that bzImage:

@george1421 Oddly, when I deploy it doesn’t show any screen that mentions bzimage or xy.init.xz at all. Is this because I am deploying using ipex.efi for booting? I am actually a bit ignorant to what these files actually do? Does the kernel boot the host client, or does ipxe.efi boot the client?

@george1421 I watched during the deploy but didn’t see anything relating to which bzimage version it is using. Odd. I have a feeling it is still using the other bzimage. I am going to test by backing up the current 4.19.101 bzimage and renaming the bzimage533 to “bzimage”. Just a temporary test.

@george1421 said in Slowness after upgrade to 1.5.7.102 (dev branch):

/var/www/html/fog/service/ipxe

Just tried the new Kernel, I moved it to: /var/www/html/fog/service/ipxe and for the Optiplex 7050 in question I changed “Host Kernel” to “bzImage533”. Is that all I had to do to make that machine image using that 5.3.3 kernel? I didn’t see a way for me to know if I was using the right kernel or not.

@george1421 Thank you for these great instructions. I am going to try it now. I did see that the partclone version that was on the screen was 0.3.12 and the image pushed at about half the speed it did previously. I am going to try this new Kernel as I haven’t tested it yet, and will report back.

@george1421 I upgraded from 1.5.7 (stable branch). I was having issues, and the dev version did indeed fix my issues but seemed to introduce new issues (the slowness). I would be very interested in testing the 5.5.3 kernel. Anything I can do to assist I am willing to. FOG is an amazing product and our desktop team lives by it here. Thank you!

We have experienced some major slowdown of deploying images after upgrading to a newer dev branch to fix some issues we had (I am now on 1.5.7.102). I went from roughly 13GB per minute to 2GB or slower per minute. Very frustrating. I tried capturing the image a couple different times with different compression and a bunch of things. Tried on multiple Dell Optiplex models and all of them display the same slowness. Got this issue on two separate servers (we have 2 campuses at our College, so two different servers). Almost feels like the different kernels did this. We were on “5.1.16 mac nvmefix” but then upgraded to the “4.19.101” which came with the 1.5.7.102 install.

I am interested in any fix for this as my desktop support team is very frustrated at the moment. I am happy to test out any theories to help this along. Would hate for others to run into this as well. Model information of the computers used is below:

Dell Optiplex 9010 - 8gb ram, core i5, 500gb crucial SSD drive
Dell Optiplex 9020 - 12gb ram, core i5, 500gb crucial SSD drive
Dell Optiplex 7050 - 16gb ram, core i7, 500gb crucial SSD drive
Dell Optiplex 7060 - 16gb ram, core i7, not sure about the hard drive

@Sebastian-Roth Absolutely. Starting new topic now. My apologies folks!

@mp12 Just curious if you ever figured out the source of your slow down? I too experienced the same major slowdown after upgrading to a newer dev branch to fix some issues we had (I am now on 1.5.7.102). I went from roughly 13GB per minute to 2GB or slower per minute. Very frustrating. I tried capturing the image a couple different times with different compression and a bunch of things. Tried on multiple Dell Optiplex models: 9010, 9020, 7050 and all of them display the same slowness. Got this issue on two separate servers (we have 2 campuses at our College, so two different servers). Almost feels like the different kernels did this. We were on “5.1.16 mac nvmefix” but then upgraded to the “4.19.101” which came with the 1.5.7.102 install.

I am interested in any fix for this as my desktop support team is very frustrated at the moment. I am happy to test out any theories to help this along. Would hate for others to run into this as well.

@Tom-Elliott Thank you for all the assistance. I actually ended up testing dev versions 1.5.7.102, and 1.5.8 and I can confirm both indeed fix the issue. Both versions now start all the services correctly after several reboots. Thank you for all your assistance Tom and everyone!

@kafluke I also was experiencing this same issue. I had deleted a bunch of data as well before trying to pull the image (ran disc cleanup wizard). I ran the exact commands you did, and it fixed the issue. Thank you and Quazz for this assistance. This forum really helps in every way with this awesome product.

@george1421 Hey there George, I thought 1.5.8 was released this morning? At least that is what my FOG login page told me. Am I incorrect? Should I wait you think?

@Tom-Elliott I noticed that a bunch of services haven’t started for me as you suspected! Wow my server is functional and works and I am not even sure how?!

I ran “systemctl --failed” and this is what I get:

[root@clone ~]# systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● FOGImageReplicator.service loaded failed failed FOGImageReplicator
● FOGImageSize.service loaded failed failed FOGImageSize
● FOGMulticastManager.service loaded failed failed FOGMulticastManager
● FOGPingHosts.service loaded failed failed FOGPingHosts
● FOGScheduler.service loaded failed failed FOGScheduler
● FOGSnapinHash.service loaded failed failed FOGSnapinHash
● FOGSnapinReplicator.service loaded failed failed FOGSnapinReplicator
● nrpe.service loaded failed failed SYSV: A simple script to autostart NRPE and allow us to easily reboot

I am going to check my server. Poor thing is an older Dell Poweredge running CentOS 7 so maybe it is just tired and slow and network or the database doesn’t start fast enough for the services?

@george1421 Thank you. I am going to update the FOG server to 1.5.8, and we will see if it fixes it. I checked and both my servers (we have 2 campuses so I set up a server on both locations) do this exact same behavior. Could be something I did wrong during install of course, but I will report back after the update to 1.5.8. Thank you for this speedy help!

My apologies if this question has already been asked. I tried to find the answer on the forum but couldn’t find it. I would like my FOG 1.5.7 server to start the mutlicast manager service automatically after a server reboot. I ran the “systemctl enable FOGMulticastManager” command but it seems to failt to start by default after a reboot. I have to start the service manually myself. When I check the service status after a reboot I get “failed”.

Is there something I need to be doing differently? I checked that the service is set to “enabled” but it still won’t start. Any thoughts?

After a reboot (ip and names blurred for security reasons):