I need you to watch the computer at the point where you post install scripts run. One of the very last steps after the post install scripts finish is “Updating database” Make sure that step is completed.

Where we see this issue, is there is a error on the target computer at the step of updating the database. But normally on capture image, because someone has changed the password on the FOG service account in linux called fog. In your case it appears you are deploying an image. Make sure your post install scripts are not accidentally rebooting the target computer before the Update Database command is executed.

If things fly by too fast for you to see, you can always setup a debug deploy. Tick the debug checkbox before you submit the deploy task. Then pxe boot the target computer. On the target computer you will see several screens of text and then eventually get dropped to a linux command prompt on the target computer. At the linux command prompt key in fog. This will start a debug deploy, requiring you to press enter at each breakpoint. It will give you a chance to see what is going on with the deployment.

Your best bet to have a standalone solution is to deploy the image to a temp computer and then capture the image with clonezilla. Both FOG and Clonezilla use partclone to capture the image, but FOG uses an image compression format not understood by partclone. You won’t have the FOG service capabilities with clonezilla but imaging will work standalone.

@fry_p Well the first thing I noticed is that you have way too many php-fpm processes running. Typically we see 5-7 process running at one time.

Below is my standard response when it comes to FOG between version 1.5.2 and 1.5.4. Ensure your settings are consistent with these:

Lets assume is the issue we’ve found after FOG 1.5.4 has been released.

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.

///

For completeness, how many computers that have the fog client installed, connect to this fog server. (round numbers are good).

@Brenth453 Well there are only a handful of reasons for it to fail here.

1. The dhcp server can’t be reached
2. The FOG server url can’t be reached from that subnet
3. FOS does not support the network adapter used

I’m kind of going to rule out #1, since the device is pxe booting and starting FOS. Typically a spanning tree issue will show up where iPXE can’t get an IP address. But it has happened at this point too.

For #2. You should confirm that you can reach the URL defined in the error screen from a computer on the same subnet as the pxe booting computer so we can rule out any kind of screening router blocking the call to the fog server.

For #3, this one is going to be a bit harder to diagnose, but its surely possible.

1. Manually register this device.
2. Go in and schedule an image deployment or capture to this device (no worries because we are not going to do either). But before you submit the task, tick the check box that says debug.
3. PXE boot the target computer. It should jump into FOS right away. You may see the same warnings about IP address, but FOS will contine.
4. After several enter key presses and pages of text FOS should drop you to a linux command prompt. At that command prompt key in
   ip addr show
5. If you get an IP address then try to ping the fog server.
6. If you don’t get an ip address then we will need to dig into what hardware you are using.

It almost appears like you still have a database issue. The boot.php file is actually a php script that interacts with the database to detect the client and what boot file and tasks are waiting. The product of boot.php is a small text file.

You could test by using a browser and key in the url http://10.149.20.67/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00 and watch the output.

You should also review the apache and php-fpm error logs in /var/logs directory for clues to why boot.php is not returning.

@tesparza for arch 6, you need to have i386/ipxe.efi for the boot file.

@tesparza for the purpose of these testing please stop the centos firewall with systemctl stop firewalld then use tcpdump command. We need to see packets that would normally be dropped by the firewall.

@Jose-Cacho said in Multicast data address not change from one task to another one:

With the change made by my workmate @Fernando-Gietz, regarding to the use of a multicast data address, we have improved the througput when there are serveral multicast tasks running at the same time. So you can mark this as solved (I don’t find how to do it).

@Developers we might want to consider @Fernando-Gietz patches for the next release of FOG.

@Zerpie To be able to capture with FOG you need to ensure the disk is closed correctly. With Win8+ shutdown is not really “shutdown”

Please use either sysprep to power off the computer before capture or use shutdown -f -s -t 0 to power off the computer and close all open files. If you use the shutdown command properly then you don’t need to worry about the hibernation files. This is not a FOG issue, but a Windows issue you will have with any disk (sector based) imaging solution.

@Fernando-Gietz How is your fog server running now that you did these updates. I still have it in the back of my head that we need to look into mysql performance number.

You have a moderately large FOG environment there. I’m wondering if you can collect some stats for me.

wget http://mysqltuner.com/mysqltuner.pl
chmod +x mysqltuner.pl 
./mysqltuner.pl

For the login credentials enter root and no password.

I’m interested in seeing what the recommendations are. You will get better results the longer mysql runs. If mysql (your fog server) hasn’t been rebooted in the last week then you should have very solid recommendations in the results.

@harryc1127 The compression format used by FOG is open source.

By default FOG uses gzip format for image compression. The FOG developers have added a new compression format that is much faster decompressing than gzip called ZSTD.

But in the end you will have a much quicker experience if you deploy your base image with FOG and then recapture with clonezilla (without letting the final target OS boot). The raw data files are one thing, but there is also the issue with the metadata files that are stored with the image information.

If you captured the source computers as single disk resizable, FOG will shrink the partition size on the reference image to the size of the data on the disk. Then FOG captures the image. If you take these compressed and shrunken disk image files, you can convert them to be used by Clonezilla but when you deploy them the partition sizes will be just a tad bigger than the data on the disk. Clonezilla won’t know how to expand the partition relative to the size of the disks. That is because that information is stored in the FOG meta data.

Its much quicker and easier to deploy with FOG and then turn right around and recapture with clonezilla. Depending on the size of your golden image and the speed of the target computer you are probably talking 15 minutes tops to deploy and then recapture with clonezilla.
But you can do it how ever you feel fits your situation. I’m only suggesting how I would go about it.

@Zerpie I’m thinking that md127 being set to inactive is also a clue. I just grabbed an old Opltiplex 780 and I’ll spin up a test workstation with the intel raid configured to see if I can duplicate the results here.

@george1421 Well this is what I see when I configured the 780 with 2 250GB disk setup in raid 0 move (stripped)

and for lsblk

I can say that I have a global kernel parameter of mdraid=true always set. When I watched FOS boot, I saw message about mdadm container assembled and then the container started. I haven’t tried to deploy to this system just yet because I need to edit the host configuration to include /dev/md126, but I’m pretty sure it will image like this. The raid array appears to be in good health.

[Edit] Yes I can affirm that it imaged correctly Windows OOBE is currently running on that system.

There is a couple of points here.

1. I’ve seen issues with some 32 bit tablets (the models escape me at the moment), in that they have a 64 bit processor, but the processor has been hardware locked in 32 bit mode. iPXE will detect its a 64 bit process (because it really is) and send the wrong iPXE kernel to the target computer. I have not check, but you might be able to bypass this auto detection by specifically calling out bzImage32 in the host configuration properties.
2. FOG doesn’t currently include refind 32 bit at part of the package. Only refind 64 bit is included. This will cause a problem when exiting from the iPXE menu in that the wrong refind kernel will try to boot and fail.

I can’t say that either of these are the specific case here, but I have seen issues before with 32 bit tablets.

@Technolust Ah, I see something…

The target computer is saying that its an EFI system (BC [type 7]), but your dhcp server is telling it to load undionly.kpxe. You should see some type of error on the target computer with NBF in the title. Basically you are sending a bios boot kernel to a uefi based system. Also make sure you have secure boot disabled on the target computer.

Fix the boot file name, the rest looks perfect.

@Sebastian-Roth Is this db information stored in the .fogsettings file? My thinking is that maybe it was changed/reset in the system before 1.5.4 was installed and the fog installer reset things to the way they were set according to the .fogsettings file(??)

@FrancoDin I don’t have this configuration setup any more, but from the error message tells me the fog bits are working correctly (even if FOG was not designed to do what you are doing). You are at the point of netbooting linux mint.

Did you remember to add the kernel argument line after the initrd line?
imgargs vmlinuz root=/dev/nfs boot=casper netboot=nfs nfsroot=${fog-ip}:/images/os/mint/18.1/ locale=en_US.UTF-8 keyboard-configuration/layoutcode=us quiet splash

(also make sure your paths are correct)

What I’m doing in this configuration its loading the linux mint kernel and inital virtual drive using the tftp protocol then by using the kernel arguments (imgargs) I’m telling the kernel to get the rest of the files via the nfs protocol (hint: nfs base directory is /images) in the path provided. From your error message I would say that linux mint has started but can’t get the rest of the files over nfs.

@zpoling Is this on a ubuntu fog server?

If so, please review this: https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

@zpoling I’ve looked at your vlan 2 pcap and there is some strangeness going on there too. I see an offer and then a nak from dhcp server in the same transaction thread. Basically that is the dhcp server saying hey I have this to offer, (I’m not seeing the client side), then the dhcp server says nak (never mind I can’t help you).

A functional dhcp/netboot process is simple

(client) Discover
(dhcp server) Offer
(client) Request
(dhcp server) ACK
(client) -> tftp server what size is file xxxxx
tftp server -> (client) its yyy size
(client)-> tftp server give me file xxxxx
tftp server->(client) here's your first block

@jgiovann Well done on getting this rolling!

The reason why 2.76 is two fold before 2.76 you would need to append .0 to all of your boot files. 2.76 and later you can just call the boot files by name. Secondly 2.76 is the first version to truly support uefi booting.
Lastly I agree that some of the documentation is out of date and should be updated. The FOG Project is built on IT volunteers and the last thing IT folks like to do is documentation.