@vince-villarreal said in Change group ID number?:

Query OK, 0 rows affected
Records: 0 Duplicates: 0 Warnings: 0
ERROR: No query specified

This message is expected based on your query (it ran OK). You didn’t update or select any rows from the database. You altered a table descriptor.

@buercky ok I see something (and its not dead people…)

For the above system you have 2 dhcp servers responding with offers.
89.0.0.92 which is giving a next server of 98.0.192.40 with a boot file of undionly.kpxe (you might want to update your dhcp server since you have Undionly.kpxe define and not all lower case undionly.kpxe)

Then you have the troubling one: 98.0.192.75 (which appears to be a dell computer) is also responding with a next server of itself with no boot file name, but it does have dhcp option 60 set indicating its a proxy dhcp server (where your error message on port 4011 is coming from).

To fix shoot 98.0.192.75 and pxe booting will start working better. Understand this is not a FOG problem but a networking infrastructure issue.

Are these windows 10 clients? If so Win 10 has a “feature” to enable dynamic mac addresses. This is done for security ( ?? ) reasons. The pending macs view are for fog client detected mac address. Where the fog client reports in to the fog server the mac addresses it detects on its network interfaces. I use a Linux Mint computer at the moment so I can’t direct you to the exact location of this switch in the Win10 gui, but it should be around the network settings.

@jflippen The last I knew the entire content of the /image/drivers directory is replicated. I do have to say we don’t change drivers much and something may have change since all of the drivers are on all storage nodes at the moment. I’ll have to confirm it still works as I thought.

both the image as well as the snapin replicator should use the lftp command defined in this file fog/lib/service/fogservice.class.php

Double checking I don’t see any other instance of lftp.

@joe-gill Ah OK, when you get back to it, we may need to up the memory settings in php-fpm since the php.ini settings are ignored by php-fpm. Understand we are still tuning the php-fpm settings. We need real world feedback to get the most appropriate settings for everyone.

@jflippen Each fog server has a local user account called fog with its own password. Have you tried to log into the remote fog server using the appropriate linux user fog password as defined in the storage node configuration for that storage node and done by ftp?

I know that was a mouth full, but the basic premise is to ftp to the remote storage node using the appropriate fog account. Change to the /images directory and ensure that you can put and delete files over ftp.

@quazz said in fogcontroller.class.php on line 260 : Allowed memory size of 3145728000 bytes exhausted:

you are running a reverse proxy Nginx

If I had to guess (unless the OP is doing something strange) that ngix might be the FOG servers. I believe that is where the FOG management gui reaches out to the FOG Project servers to get the information, both on the login and configuration pages.

The memory exhaustion issue could be php-fpm but that issue should have been fixed with FOG 1.5.4. We can test if it is php-fpm by turning it off in the configuration file to see if the memory error is coming from there. I can see issue #1 could be related to the tighter (more exact) restrictions on php code than apache php.

@howtogravity OK to test if your updates are correct. Please post the output of these commands.

sudo lsblk
and
sudo df -h

The first command shows the block devices (i.e. storage devices) that your fog server knows about.

The second command shows how your storage devices are connected.

@k-hays said in Issues with Fog 1.5.2:

. would 90 be a stretch?

Don’t do that much you could run into a situation of resource exhaustion. Under normal imaging you shouldn’t see more than 10 worker thread. For max children I would set it to 40.

If you are using FOG 1.5.2 or later here is what I would change in the www.conf file for php-fpm.

php_admin_value[memory_limit] = 256M
pm.max_requests = 2000
pm.max_children = 40
pm.min_spare_servers = 6
pm.start_servers = 5

Update those settings then restart php-fpm.

Queue up your multicast then on the fog server linux console start top then press P to sort by CPU usage. Watch, you should have 5-7 php-fpm worker threads running, they should be the top cpu users.

@k-hays Between FOG 1.5.0 and 1.5.1 (or 1.5.1 and 1.5.2 sorry I can’t remember) the developers switched from using the built in php engine in apache to using a dedicated php engine (php-fpm). This was done to address an issue with GUI slowness reported with the new 1.5.x Web GUI on certain distributions. Baseline testing then showed an excellent improvement in GUI responsiveness as well as client check ins were not causing an issue with heavy web server load as they were before.

After 1.5.2 was released the developers started seeing other reports of issues with multicasting and unicasting in larger environment that wasn’t see during development. So certain tweaks to the php-fpm config files were made in 1.5.3 and 1.5.4. Increasing the memory limit even more to 256MB resolved a multicasting issue was discovered after 1.5.4. was released. That setting will be in 1.5.5 when its released in a few months. With these new settings you should see a pretty stable multicasting deployment.

I wonder if its related to a php time being off. Since you are PDT, I might have expected it to be a day ahead not behind if php is using UTC time.

Is the system timezone set correctly?
Do you have the timezone set correctly inside the fog gui (FOG Settings)?

Lets collect a bit more information here.

1. What version of FOG are you using?
2. You captured an image from a reference computer, what hardware was that reference image created on?
3. Is the hardware you are deploying that image to the same as the source computer?
4. Did you capture the image as single disk resizable?
5. Is the target hardware running in the same mode as the source computer (i.e. bios and bios, or uefi and uefi?)

Something you might consider.

login
kernel nfs://10.100.0.55/winimgs/iso/Winpe/wimboot gui
iseq ${platform} pcbios && goto mem_bios || goto no_mem
:mem_bios
initrd -n bootmgr.exe    nfs://10.100.0.55/winimgs/iso/Winpe/bootmgr.exe bootmgr.exe
goto mem_cont
:no_mem
initrd -n bootx64.efi   nfs://10.100.0.55/winimgs/iso/Winpe/bootx64.efi                 bootx64.efi    
:mem_cont
initrd -n bcd           nfs://10.100.0.55/winimgs/iso/Winpe/BCD                         bcd
...

Also realize that ${fog-ip} is a variable that expands out to the IP address of your fog server. If you use the variable it makes your pxe menus portable between FOG servers.

@mparlette Ok you have a few things to work on.

First I would set your system timezone correctly (not UTC). Understand this is the linux timezone setting of your linux distro. Once that is set, then in the fog gui under Fog Settings->Fog Configuration expand all menus and search for time make sure that is right. Once all are set correctly reboot the fog server. From then on your times should be correct.

@mparlette said in Date off in dashboard #253 - Github:

CentOS 7 w/ FOG 1.5.4
/etc/php.ini date.timezone entry was commented out.
corrected with:
date.timezone =“America/Vancouver”

Technically that may not help you. In a normal world it would. But in FOG’s case its using php-fpm which has its own opinion of things and if you have php 7.x installed then the /etc/php.ini file is typically not referenced since php 7 has this file in a different path.

But having the OS and fog menus in agreement should get you to where you want to be. So good job!!

Why did you install fog 1.5.1 instead of 1.5.4?

I can say I think there is an issue with Debian 9.4 installer for FOG that does not create the config file properly for php-fpm. If this is the case you will have a very slow UI in 1.5.2 and later version of FOG.

There is a quick test to see if php-fpm is configured correctly. Open a linux console and run top then press P to sort by CPU usage. You should have php-fpm at the top of the processes. There should be 3 or 4 instances running. If apache is at the top then php-fpm is not configured correctly on your FOG server.

There are a few tweaks needed to FOG 1.5.4 that was discovered after 1.5.4 was released. Once we are sure that php-fpm is running then we can look at those settings.

@jflippen Just as an idea (first let me say I’m not a programmer), if you look about in the code where you can find an example of the replication agent writing to a log file. Clone that and place it in the correct location in the code to write both md5 hash codes into the log. Once the fog server has restarted then it should log that information into the replicator log file. I’ve had to do somethings similar in the past to reverse engineer some of the magic Tom does with his code.

Lets assume is the issue we’ve found after FOG 1.5.4 has been released. Similar posts have addressed other multicasting issues with FOG 1.5.4. What the developers have seen is that under certain conditions php-fpm runs out of usable memory during a multicast. Probably the most useful value to you is bumping the memory from the default of 32MB to 256MB.

1. Change to the /etc directory from the fog server linux command prompt.
2. Search for www.conf file. It can be in a number of locations depending on what version of php is installed. Use this command.
   find /etc -name www.conf (hopefully you will only find one)
3. Edit that file file and ensure these settings are accurate. Don’t just add them since all should be there except php_admin_value[memory_limit] = 256M you will need to add that entry.

php_admin_value[memory_limit] = 256M
pm.max_requests = 2000
pm.max_children = 35
pm.min_spare_servers = 5
pm.start_servers = 5

4. Save and exit your text editor.
5. Reboot the fog server.
6. See if that fixes what is wrong. You really should only see this strangeness under heavy load, but I guess it might show up sooner under certain conditions.

Also we found there is something strange going on in the linux kernels after 4.15.2, I’m going to recommend that you downgrade your FOG/FOS kernel to 4.15.2. The issue with later kernels is that its taking 3-5 minutes to create the disk structure under certain circumstances, where with 4.15.2 and older its only seconds to create the structure.

Now the kernel will not impact your issue, but processing is incomplete might be related to the missing php-fpm configuration setting.

@stucraster I have a tutorial around moving your imaging files off the root partition here: https://forums.fogproject.org/topic/11048/moving-fog-s-images-files-off-the-root-partition-2017-edition

Usefull commands are lsblk to show block devices (i.e. storage devices) and df -h to show mounted disks.

Do you have an unmanged (dumb) switch to place between the pxe booting computer and your building network switch.

Your condition sounds like a spanning tree issue, where you are running standard spanning tree and not one of the fast spanning tree protocols (RSTP, MSTP, fast-STP, etc). I specifically think this because time corrects the iPXE dhcp process. Placing an unmanged switch between the pxe booting computer and the building network switch keeps the building switch port from dropping during the pxe booting process and is a quick indicator of traditional spanning tree protocol.

Side note: roll your FOS kernel back to 4.15.2 to have a better experience with UEFI / GPT disks. There is a regression bug in 4.17.0 that the developers haven’t been able to correct just yet.