@george1421 Sorry, I mixed up terminology there.
The Fog-Client-Service runs just fine (i use setupcomplete to enable it and then start it, and yes it is set to delayed start, but that usually works out fine somehow.
I’m talking about the service settings in the fog webgui.
It happens to me as well, but so far I would have assumed that I just forgot to activate the service settings for the machines where it happens, but it does happen quite often.
FOG latest RC
OS Centos 7
Images being installed are Win10 - 1709
Never mind - I got it working but finally moved away from the idea of having both services on the same server.
One service per server seems to be more appropriate in a VM-surrounding as it is with our servers.
Thanks!
It does. Thanks!
While George’s solution might have worked for the “bug” the cleaner solution is probably doing it right with the partition order…is it “frech” to mark my own post as solution?
Soooo…
Didnt do the suggested thing yet because I had another problem with my partitions - had to resize the Data Partition in my VMs hard drive in order to install the Windows 10 Fall Creators Update 1709 - and decided to change the partition order while I was at it. Turns out that is not as easy as I would have hoped.
If anybody else needs to move their EFI Partition sometime in Windows:
Situation: You have a system set up for UEFI. You have your data partition and after that the EFI GPT Partition.
When I speak of after or left and right its always as displayed in the Windows Disk Management from left to right.
Make a BACKUP !! - before anything else.
Use a Partition Tool (e.g. Minitool Partition Wizard or anything else you’re familiar with, M-PW is free) and make sure that you have a free space preceding your Data partition that is at least as big as the EFI GPT Partition behind your Data Partition. For example you can Resize your data partition to free some space and make it unallocated at the right position (which is left of the data partition).
Copy the existing EFI GPT Partition to the free unallocated space.
After reboot - necessary to apply changes - reboot again using gparted live ISO / USB / whatever suits you (https://gparted.org/
In Gparted: Set the flags for the new copied EFI Partition to: Boot & ESP (Right click on the partition -> manage flags)
You can also delete the old EFI partition in this step if you aren’t afraid - if you delete it and your copy doesnt work you are probably going to be stuck with a non-booting system. Again, make sure you have a backup / snapshot.
After letting gparted do its thing and rebooting into Windows you should have the correct order of partitions down.
In my machine the order from left to right is now as follows:
Recovery partition
EFI Partition
Windows 10 Data Partition
I’ll try and update if anything changes.
Not sure either 
Sysprep CAN generalize your image and make it hardware independent.
But it doesn’t have to. What it does is reset the installed windows on an image so that for the next install it will go through all the steps that you normally would when activating windows on a new machine.
And it allows you to preinstall programs, use an autounattend file to create users, make settings for languages / keyboards / etc. etc.
Just a wild guess: But with Windows 10 and its Meltdown and Spectre Patches there was a massive problem with Antivirus-Programs causing Bluescreens.
Just make sure that you dont have the Windows 10 Meltdown / Spectre Patches installed and an Antivirus that isnt compatible?
Hi and thanks for your feedback and suggestions so far.
I will try changing the d1.fixed… file as suggested and see what happens.
Regarding the changes:
The change from MBR to UEFI did happen, but has been made already a long time ago. So not with the most recent changes to the image.
The image is an english international Windows 10 Professional but there is a german language package installed.
File contents as suggested:
d1.fixed_size_partitions
:3:1
d1.minimum.partitions
label: gpt
label-id: 06F1156D-A1CD-11E7-B138-080027E94607
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 104857566
/dev/sda1 : start= 2048, size= 1024000, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=06F1156A-A1CD-11E7-B138-080027E94607, name="attrs="RequiredPartition GUID:63"
/dev/sda2 : start= 1026048, size= 103626240, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=06F1156B-A1CD-11E7-B138-080027E94607
/dev/sda3 : start= 104652288, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=06F1156C-A1CD-11E7-B138-080027E94607, name="attrs="GUID:63"
d1.partitions
label: gpt
label-id: 06F1156D-A1CD-11E7-B138-080027E94607
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 104857566
/dev/sda1 : start= 2048, size= 1024000, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=06F1156A-A1CD-11E7-B138-080027E94607, name="attrs="RequiredPartition GUID:63"
/dev/sda2 : start= 1026048, size= 103626240, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=06F1156B-A1CD-11E7-B138-080027E94607
/dev/sda3 : start= 104652288, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=06F1156C-A1CD-11E7-B138-080027E94607, name="attrs="GUID:63"
Thank you for your support!
Thanks for the update Tom.
Really appreciate everything that is being done.
I’m not a developer, if there is anything besides posting on the forums when I have time that can be done I would happily help, just shoot me a pm.
And regarding donations: I will see if we can make some of our budget available for a donation … our NPO is sadly very restricting regarding funds at the moment. But we will see
Re: Hard drive resize is not expanding
Well … not sure its the exact same problem, thus opening the new thread, we can merge if its the same.
I am using FOG to install our Windows 10 Golden Image via the network.
The install works fine on most computers, BUT: The image no longer expands to fill the partition as it used to.
I did change a few things in the Golden Image prior to it no longer working, but nothing that I could think of that has to do with any partition or HD - size related stuff. Answer file is as was. Image type is still single disk resizable. The image has about 48Gig on Client.
No error messages during install as far as I can see.
Running FOG on a Centos Server, installing Windows 10 Professional 64Bit from an updated Golden Image that used to work.
FOG is on 1.5.0 RC-10
Any ideas where I can start looking?
Thanks for the help, disabled the active bit and after a reboot ‘top’ no longer shows any process with high CPU usage in idle state.
In the long term the question remains: Why did that happen at all and is it related to our error regarding the web-gui “freeze” when looking at scheduled tasks?
Update:
Just checked: I can now open the “Scheduled Tasks” website in the FOG-Gui without problems …
I just tested with the minus (-) from a command prompt on my Windows 10 Client here, works fine.
Happy to give hints where I can, had to do something similar from scratch as well. Also, everybody here on the forums is extremely helpful.
So if you have specific questions, we can definitely try to point you in the right directions.
Fogscheduler Log:
[12-13-17 11:13:05 am]
==================================
=== ==== ===== ====
=== ========= == === == ===
=== ======== ==== == ==== ===
=== ======== ==== == =========
=== ==== ==== == =========
=== ======== ==== == === ===
=== ======== ==== == ==== ===
=== ========= == === == ===
=== ========== ===== ====
==================================
===== Free Opensource Ghost ======
==================================
============ Credits =============
= https://fogproject.org/Credits =
==================================
== Released under GPL Version 3 ==
==================================
[12-13-17 11:13:05 am] Interface Ready with IP Address: 127.0.0.1
[12-13-17 11:13:05 am] Interface Ready with IP Address: 127.0.1.1
[12-13-17 11:13:05 am] Interface Ready with IP Address: 192.168.43.17
[12-13-17 11:13:05 am] Interface Ready with IP Address: fogserver
[12-13-17 11:13:05 am] * Starting TaskScheduler Service
[12-13-17 11:13:05 am] * Checking for new items every 60 seconds
[12-13-17 11:13:05 am] * Starting service loop
[12-13-17 11:13:05 am] * 3 tasks found.
**And the Apache error log:**
[Mon Jan 01 03:38:22.208005 2018] [auth_digest:notice] [pid 12312] AH01757: generating secret for digest authentication ...
[Mon Jan 01 03:38:22.208797 2018] [lbmethod_heartbeat:notice] [pid 12312] AH02282: No slotmem from mod_heartmonitor
[Mon Jan 01 03:38:22.225832 2018] [mpm_prefork:notice] [pid 12312] AH00163: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.6.32 configured -- resuming normal operations
[Mon Jan 01 03:38:22.225842 2018] [core:notice] [pid 12312] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[Wed Jan 03 11:18:17.743911 2018] [:error] [pid 10603] [client 192.168.43.93:25534] PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 35505 bytes) in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 261, referer: http://fog.lfdw.local/fog/management/index.php?node=host&sub=edit&id=165
[Wed Jan 03 11:18:48.656285 2018] [:error] [pid 23214] [client 192.168.43.93:25548] PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 35505 bytes) in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 261, referer: http://fog.lfdw.local/fog/management/index.php?node=host&sub=edit&id=165
[Wed Jan 03 11:20:26.383096 2018] [:error] [pid 23214] [client 192.168.43.93:25585] PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 35505 bytes) in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 261, referer: http://fog.lfdw.local/fog/management/index.php?node=host&sub=edit&id=165
[Wed Jan 03 11:26:43.136156 2018] [:error] [pid 23402] [client 192.168.43.93:25747] PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 35505 bytes) in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 261, referer: http://fog.lfdw.local/fog/management/index.php?node=host&sub=edit&id=165
[Wed Jan 03 11:29:43.869919 2018] [:error] [pid 10603] [client 192.168.43.93:25822] PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 35505 bytes) in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 261, referer: http://fog.lfdw.local/fog/management/index.php?node=host&sub=edit&id=165
[Wed Jan 03 11:48:19.361457 2018] [:error] [pid 10603] [client 192.168.43.93:26266] PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 35505 bytes) in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 261, referer: http://fog.lfdw.local/fog/management/index.php?node=host&sub=edit&id=165
[Wed Jan 03 11:54:39.077064 2018] [:error] [pid 23270] [client 192.168.43.93:26420] PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 35505 bytes) in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 261, referer: http://fog.lfdw.local/fog/management/index.php?node=host&sub=edit&id=165
[Wed Jan 03 11:56:01.568297 2018] [:error] [pid 23305] [client 192.168.43.93:26450] PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 35505 bytes) in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 261, referer: http://fog.lfdw.local/fog/management/index.php?node=host&sub=edit&id=165
[Wed Jan 03 12:20:25.820408 2018] [:error] [pid 23305] [client 192.168.43.93:26935] PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 16384 bytes) in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 261, referer: http://fog.lfdw.local/fog/management/index.php?node=host&sub=edit&id=165
[Wed Jan 03 12:37:30.868478 2018] [:error] [pid 23305] [client 192.168.43.93:27362] PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 49152 bytes) in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 261, referer: http://fog.lfdw.local/fog/management/index.php?node=host&sub=edit&id=127
Regarding the schedules:
I still have the problem that when trying to show my scheduled tasks the web gui hangs and I cannot open any more pages on the webgui until I delete my browsers data (cookies, etc.) - tried with several different browsers and seems (at least according to what i took from the thread where I posted that) to be a problem with my setup only … since we dont necessarily need the scheduled tasks I just ignored it so far.
Will try a reboot now.
Update:
Rebooting the machine puts the FOGTaskSchedule at the top with 100 % CPU again, 0.2 % Mem … the httpd ones are still at the top but with much lower cpu values, sometimes going down to 0.
Re: Support regarding CPU usage of FOG server
Hello again.
So, the CPU Usage is still very high on our FOG Server running in our Virtual Machine. I get an error about high CPU Usage in the vcenter.
Looking at the ‘top’ command I get:
PID | USER | PR | NI | VIRT | RES | SHR | S | %CPU | %MEM | Time+ | COMMAND
12319 | apache | 20 | 0 | 678888 | 25616 | 8032 | R | 99.7 | 0.3 | 30414:05 | httpd
15481| root | 20 | 0 | 344072 | 13316 | 3220 | R | 99.7 | 0.2 | 30414:31 | FOGTaskSchedule
23216 | apache | 20 | 0 | 521388 | 22732 | 5728 | R | 99.7 | 0.3 | 175:46.18 | httpd
as the top three processes, everything else doesnt seem to tax the cpu at all (0.0 or 0.1 mostly for CPU%)
The VM is set up with 4 CPUs with 2 Cores. There is about 20 servers running on that VM Server, none other seem to have CPU issues.
We have about 160 Machines connected to the FOG server at very peak times, usually about 60-80, no Tasks scheduled (due to it still not working for us, but thats a different story) and no replication set up.
There is about 6 images on the server (including Hirens Boot CD and two other “tool menu options”), 2 of which we use now and then to update single machines to the newest golden win10 image version.
The only person accessing the fog server to manage it is me from one computer only. Closing the browser windows on my client that access the FOG UI doesnt seem to change anything in the ‘top’ command.
Running:
Running Version 1.5.0-RC-10
SVN Revision: 6080
On CentOS, up to date as of a few days ago, problem has persisted for longer than that.
Would any other information help us in solving this? Thanks for your support!
Update: I ran the database cleaning commands from the wiki - no change.
And the top of the ‘top’ command shows:
top - 14:27:09 up 72 days, 20:01, 1 user, load average: 3.01, 3.38, 3.28
Tasks: 198 total, 4 running, 194 sleeping, 0 stopped, 0 zombie
%Cpu(s): 75.2 us, 0.2 sy, 0.0 ni, 24.5 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st
KiB Mem : 8010576 total, 1167556 free, 848008 used, 5995012 buff/cache
KiB Swap: 4063228 total, 4063228 free, 0 used. 6760720 avail Mem
Results in this:
total 53756
drwxr-xr-x. 2 fogadmin apache 243 Oct 16 12:20 .
drwxr-xr-x. 3 apache apache 4096 Oct 16 12:20 …
-rw-r–r–. 1 fogadmin apache 1966 Oct 16 12:20 advanced.php
-rw-r–r–. 1 fogadmin apache 16272 Oct 16 12:20 bgdark.png
-rw-r–r–. 1 fogadmin apache 21280 Oct 16 12:20 bg.png
-rw-r–r–. 1 fogadmin apache 1139 Oct 16 12:20 boot.php
-rw-r–r–. 1 fogadmin apache 8069680 Oct 16 12:20 bzImage
-rw-r–r–. 1 fogadmin apache 7853680 Oct 16 12:20 bzImage32
-rw-r–r–. 1 fogadmin apache 234697 Oct 16 12:20 grub.exe
-rw-r–r–. 1 fogadmin apache 592 Oct 16 12:20 index.php
-rw-r–r–. 1 fogadmin apache 18721596 Oct 16 12:20 init_32.xz
-rw-r–r–. 1 fogadmin apache 19553652 Oct 16 12:20 init.xz
-rw-r–r–. 1 fogadmin apache 25340 Oct 16 12:20 memdisk
-rw-r–r–. 1 fogadmin apache 1839104 Oct 16 12:20 memtest.bin
-rw-r–r–. 1 fogadmin apache 20976 Oct 16 12:20 refind.conf
-rw-r–r–. 1 fogadmin apache 205192 Oct 16 12:20 refind.efi
@Sebastian-Roth
Thanks for your help.
So, something that has troubled us in the past (auto renames of hosts to names that are assigned to other hosts) was that we use usb3-docking-stations on a lot of our setups. So I assume that a computer that was attached to a docking station when registering with FOG via the client took the Docking Stations MAC Adress and registered it. This may have happened with several clients. Attaching a new computer to a docking station with force reboot hostname change active then changed the new computer to the old computers settings.
I have been trying to figure out a way to get all the docking stations mac adresses and have fog ignore them, but there seems to be little similarity in the docking stations mac adresses … So for the moment I am struggling with finding out which host uses a docking stations mac as primary mac to make them ignore it.
I was even considering deleting all the hosts for our rollout today to make sure that they get registered with their correct mac’s - since we have to connect them directly to the lan port for fog to do its thing anyways … but I am worried it might throw more problems than its worth …
Regarding the Kernel:
With the working branch fog that I installed a few days ago the problem with the install button (Screenshot: https://drive.google.com/open?id=0B_yYSiicYNIARjQ2eHJXTS1RV28) - it now is clickable.
But when I clicked on the button I get an error now: https://drive.google.com/open?id=0B_yYSiicYNIAX3Qyek0wZVNMNDQ
EDIT: Same kernel update error for this user here - https://forums.fogproject.org/topic/10978/uefi-lenovo-miix-320-and-usb-ethernet/2