@Yanni Well lets see if we can find the problem. I have a good idea, but lets see if we can find it.

First while this isn’t “the” problem it might cause you an issue.

1. Change your dhcp scope to not include the FOG server. Set the starting address for dhcp to 10 or something more than 2.
2. Make sure your fog server has a static IP address and it doesn’t change after FOG is installed. The FOG Installer hard codes some IP addresses into the configuration so it make it a bit more difficult to change the fog server’s IP afterwards.

Do you know how to use wireshark? If yes then configure a boot filter of port 67 or port 68 . Have your wireshark computer on the same subnet as the pxe booting computer and start wireshark. Now pxe boot the target computer until you get the tftp error. Stop wireshark. You should have a Discover, Offer, Request, Ack packet DORA. Look in the Offer packet from your dhcp server, in the ethernet header there should be a next-server and then boot-file values. That should be the fog server’s IP address and undionly.kpxe. Now look into the dhcp options, dhcp options 66 and 67 should be set correctly. I have seen firewalls ignore the boot server info and always put the firewall’s IP address in for the boot server. I suspect that is the problem here.

If you don’t have/know wireshark then you can use this tutorial to collect the pcap using the fog server: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue?_=1696275644673 You can then post the pcap to a file share site and either post the link here or DM me using FOG Chat and I will take a look at it.

@kalafina The last line of the apache error log looks interesting. Error dispatching … index.php. That is the home page of the fog server. But why is it having an issue.

When you installed fog there are 3 steps. Install fog using the console on the linux server, go to the web ui and install the database and then go back to the fog server console to complete the last steps in the install. Did you do all 3 steps? If no or not sure rerun the fog installer and it should fix things. There is something abnormal with your current install.

@kalafina OK it looks like you have all of the parts in place. The next thing you should look at is in /var/log directory. Look in the apache2 folder for any error logs that might be helpful to tell why apache isn’t happy, as well as in the php-fpm directory for the error logs there too. Something has to be reporting a problem that not being sent to the browser.

@kier056 What values do you have defined for dhcp option 66 and 67 on your dhcp server?

@kalafina Is this a new install of FOG?

The FOG web site is powered by php. Make sure php is installed as well as a service called php-fpm and its running. Also make sure there are files in /var/www/html/fog directory.

@boros Is this possible to do, probably yes.

There are a few approaches you can do depending on how comfortable you are with syslinux.

Lets get some common terms here.

FOG uses a boot loader called iPXE. Syslinux is al alternate to iPXE. What you can do with syslinux you can do with iPXE. iPXE has two boot loaders depending on the firmware version of the target host. For bios computers the boot loader is undionly.kpxe and for uefi its snponly.efi or ipxe.efi.

So if you still pxe boot with syslinux, you will have to chain load ipxe from your fog server from syslinux.

An alternate is to pxe boot into FOG using ipxe and then call WDS from a custom fog ipxe menu and do away with syslinux since ipxe will be doing that function. I have a tutorial here on how to pxe boot into different OS installers from FOG: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

The structure of a syslinux config file is similar to iPXE so its possible to translate the formats and commands between the two different boot loaders.

@jfernandz Will you provide a screenshot of the error? I’m thinking this error is coming from FOS Linux (not the fog server host OS), but not sure what its doing to require the lock file.

@iljared98 Without having the hardware in hand I can’t say it will boot or not.

But in general areas where there might be a problem,

1. firmware settings that cause it to not pxe boot right
2. New hardware that is not supported by iPXE yet (we can work through the ipxe update process to get the latest version)
3. The FOS Linux kernel won’t boot, but we can debug the kernel to find out why.

@sgilbe I haven’t found the right combination to start with a clean kernel and just to get it to run on a standard system. But I do have to admit I haven’t had a lot of extra time lately to work on this.

As for needing a new init.xz. Its not at that point yet. The kernel boots and inits the hardware then connects to the init.xz to startup linux. The issue is within the kernel at this point. It may be as Sebastian mentioned that there was a patch that ubuntu added to make the kernel boot. I’m not at a give up point, but there has to be a solution here.

@iljared98 While I don’t use this model, go into the firmware and see if there is a raid-on mode. Change it back to ahci mode then it should image with fog. There are other things to try but lets start there.

Also you didn’t mention the version of FOG you are using, because iPXE might need to be updated to support new hardware.

@jptechnical If the laptop is in uefi mode there is a way to boot from a usb drive: https://forums.fogproject.org/topic/6350/usb-boot-uefi-client-into-fog-menu-easy-way

There are other options but try the easy way first.

@skyborne98 Its still a password issue. Look in the storage node configuration document for the storage node that is accepting this image. There is a ftp user ID and password in that configuration document, my guess is the password defined there is not in line with the actual linux account.

@herman Debugging this may be difficult. What changed between 5GB/min and now 270MB/min?

I’m going to suspect network issues, but what specifically changed?

@davidgoncalves If you look in /images/dev directory do you see sub directories there that appear to be mac addresses? These should be consistent with mac address of the source computer. Under normal conditions there should not be any of these directories in the /images/dev folder unless there is an active capture going on.

@alexamore90 Let me make sure I understand the problem here.

You ave two esxi servers one is Dell and one is HP. The Dell has 3 VMs that are FOG servers 1, 2, 3. The HP has only one FOG server A (as an example).

So your problem is that on the Dell when you have multiple unicast deployments you have on average 3GB/m deployment rate, but on the HP you only get 1/2GB/m rate. Is that your problem?

If that is the problem, the first thing I don’t know is what is the differences (hardware wise) between the Dell and HP (CPU cores, RAM, network bandwidth) Also how busy is the Dell vs HP servers? Are these ESXi boxes performing any other tasks?

I doubt its the FOG server that is the root of the problem here. As a test you can export FOG1 as an OVA file and then import it onto the HP. Stop FOG1 on the Dell and then power it up on the HP. Do you see the performance differences still between the Dell and HP? If yes than the problem is with the HP and not specifically with FOG.

@alexamore90 My intuition is giving me doubt in a few things here.

First lets get our scale correct so that we can be sure we are talking about the same things.

The speed you mentioned is probably from partclone image deployment. If yes then that scale time frame is volume per minute. So when you image 10 pcs at a time you get 3GB/minute and a single pc you can get 16-17GB/m (I have doubt on this single pc speed)

Let me explain, you have a 1GbE network switch, so your link from the ESXi box to the tp switch is 1GbE. So 1 GbE == 1000 bits per second == 125MB/s == 7.5GB/min (theoretical speed) In theory its possible to get to 16GB/m but its doubtful.

The number you see in the partclone screen is a composite speed. That is the combined speed for the fog server to move a block of data from its local storage, the time it takes to transmit the data over the network, network transport time, then on the client to receive the block of data, decompress the data and write it to the target computer’s local storage media.

So since that speed in partclone is a composite score, its possible to have a partclone speed faster than the theoretical speed of a 1GbE network connection. If you have a very fast target computer and a highly compressed image.

Now with a single 1GbE network link in testing I’ve saturated that network link at 3 unicast imaging. Past 3 simultaneous unicast imaging with a saturated link performance drops off quite a bit.

On a well managed 1GbE network I would expect to see 6-6.5GB/m transfer rates. On a 10GbE core network with 1GbE access layer I would expect to see between 13 and 15 GB/m.

Almost all of the heavy load of imaging is done by the target computer. The fog server only moves data from its local storage, to the network adapter and then monitors the overall imaging process. I can run FOG on a raspberry pi server and get 5GB/m transfer rates. The size of the fog server really doesn’t have an impact on imaging speed as long as the server can get a data block from its local storage media and out the network adapter.

So how can you make FOG imaging go fast if you want/need to have multiple unicast imaging streams going?

1. Have a fast disk array with multiple spinning disks or SSD disk.
2. Have either multiple ethernet adapters configured in a LAG configuration to your network switch or run a 10GbE link between your fog server and network infrastructure.
3. Use enterprise class network switches. Those TP switch are low end switches with limited backplane speed. Even used / older enterprise (managed) switches may be faster.

If you can’t change any of the above, and you need to image multiple computers at the same time consider looking into FOG multicast imaging.

@sgilbe Well my first attempt to rebuild the kernel gave me the same results as you. Not what I expected so I need to work a bit more. If I can get something that boots in the next day or so, are you willing to test to see if it resolves your booting issue?

@jjurak Is this something you are actively looking to do?

If yes, do you use the fog client program? If yes that will be the problem. The fog client is hard coded to use port 80. I’ve been asking for a few years to decouple the fog client communication port from the management ui. But there has been other issues that have taken priority.

If you are interested in doing this I can probably give you a few areas to look.

@sgilbe Do you still have access to this server?

@Numa09 First this looks like a DOS Batch file not a VBS file. That is maybe why its giving you an error with line 2.

Second make sure that csv file is part of your snapin pack.