@george1421
ah that’s unfortunate.
Thank you for informing me of this limitation with iPXE.

When writing /dev/sda I an seeing a range of 5.7GB - 6.1GB
But early in the process when its doing the other partitions its at ~16/GB I was hoping to have this rate be consistent with all partitions.
This is with all 1GB Ethernet connections.
Have there been tests done with raid arrays?
Would hosting this on a Raid 0 paired with a 10Gb connections on the nodes help decrease the imaging times by a sizeable amount?

Hello! I recently considered increasing the MTU size in my network to see if it would reduce imaging times.

As of right now my tests are being done in a hypervisor to see if it would be worth it.

My NIC port is set to 8972 MTU
the Bridge for the VM that hosts fog and the test VM is also set to 8972 MTU

For the OS running fog I set the MTU to the same value
using this command

sudo ifconfig ens18 mtu 8972

but when I try to PXE boot with all these settings in place
I am met with this

When I set the bridge MTU back to 1500
I am able to PXE boot properly and get to the fog menu with no issues.

All of my PXE/fog related files are being hosted on 192.168.2.43
My routers MTU is also set to 8972

so far this issue is only affecting my VMs, when I PXE boot my supermicro system it is able to get to the fog menu with no issues, but chances are its MTU is by default set to 1500.

@george1421
This did the trick!
Thank you!
My raid array was made with software raid on Ubuntu.

FOS recognized and assembled the raid array!
with that I updated the hard drive field.
I am now able to capture and deploy the OS with no issues!

Also is fog able to capture both the OS SSD data and raid array data on the NVMe drives?
While testing the solution you provided I captured and deployed the OS a handful of times but unfortunately the data on the raid array remains intact and doesn’t revert back to the state it was when the OS was initially captured.

Is there a solution for this or does FOG not have the ability to capture and deploy raid array data on a separate drive that isn’t the OS?
Using your solution I created a new image and set the host drive to the raid array from FOS to see if I could capture just the raid array data but it won’t be captured due to it not having linux/resizable partitions

@george1421
This did the trick!
Thank you!
My raid array was made with software raid on Ubuntu.

FOS recognized and assembled the raid array!
with that I updated the hard drive field.
I am now able to capture and deploy the OS with no issues!

Also is fog able to capture both the OS SSD data and raid array data on the NVMe drives?
While testing the solution you provided I captured and deployed the OS a handful of times but unfortunately the data on the raid array remains intact and doesn’t revert back to the state it was when the OS was initially captured.

Is there a solution for this or does FOG not have the ability to capture and deploy raid array data on a separate drive that isn’t the OS?
Using your solution I created a new image and set the host drive to the raid array from FOS to see if I could capture just the raid array data but it won’t be captured due to it not having linux/resizable partitions

I am trying to capture an Ubuntu server 22.04 image with a raid0 array set up so that I can roll back to this base image without having to recreate the array.

The OS is on a SATA SSD while the raid array is made from x2 NVMe drives in a dual slot nvme card.
nvme0n1 and nvme1n1
Unfortunately Fog appears to be having issues with my NVMes
Is there a fix for this?

another issue I have is when I deploy an image it gets imaged to the NVMe and not the SATA SSD, is there a solution for this as well?
I have been bypassing this by removing the NVMe card but it would be nice not to have this issue anymore.

@george1421
Just to clarify My Pihole is saying it is the ProxyDHCP server which is why the system is trying to boot to the pihole IP?

Is pihole still considered a ProxyDHCP if it’s the only DHCP server/service in this network?
I do not believe this Pihole VM has dnsmasq installed as I tried restarting the dnsmasq service.

So to clarify on the packet situation, this current setup has Pihole sending out the correct information but it’s also saying it is the proxyDHCP so when the fog server receives those requests it’s sending back offer packets with Pihole as the next server?

Do you know what could be overriding the ltsp.conf in the pihole server and directing packets to itself?

@george1421

Hey! I really appreciate you helping me out!
Sorry for the late response I made this a few minutes before heading to work and I gave the wrong IP for my DHCP server.
All of this except my router is being hosted on VMs through Proxmox.

Right now my Pihole is acting as my DHCP server at IP “192.168.2.60”
IP “192.168.2.120” was my DNSMASQ server. I have turned this VM off due to the fact I was not able to tell if I was configuring it right.

Right now I have
Pihole as my DHCP at IP 192.168.2.60
Fogserver at IP 192.168.2.91

I have followed your guide and collected some packets on both my fogserver and pihole while the test system powered on and attempted to PXE boot on it.

from port 67
[
piholeoutput.pcap
fogserveroutput.pcap
]

from port 4011
[
fogserverport4011.pcap
piholeport4011.pcap
]

I have been staying up late trying to get this fog server set up for almost a week now, if you are not able to see what I am doing wrong I am extremely open to erasing all my VMs and starting from scratch, these VMs don’t have important data on them.

I have attached new updated images of what my current configuration is on my Pihole.

Here is a quick run down of how I have set up my current configuration.

After creating a new VM I installed Pihole, from there I went to the web console and enabled the DHCP server option.
I disabled the DHCP server option on my router as well.
I then went to /etc/dnsmasq.d and created ltsp.conf
I used the file format and settings from here

https://docs.fogproject.org/en/latest/installation/network-setup/proxy-dhcp/#dns-masq-ltsp-settings

Afterwards I installed tftp on the pihole server using the commands from the highly voted comment.
https://askubuntu.com/questions/201505/how-do-i-install-and-run-a-tftp-server

I then downloaded the undionly.kpxe file to the root /tftp folder from here
https://ipxe.org/howto/chainloading

Afterwards, I created a new VM to install fog using this guide
https://docs.fogproject.org/en/latest/installation/server/install-fog-server/#final-steps

I then also installed tftp on this server and repeated the same process I did on pihole.
The fog server VM also has the undionly.kpxe file in /tftp

Unfortunately, I do not recall what I selected for each of the prompts during the install but I can roll back to the snapshot of the VM I have prior to the install if needed.

Here is the contents of my ltsp file in my dnsmasq.d directory.
My fog server IP is 192.168.2.91
The IP the VM dnsmasq is being hosted on is 192.168.2.120
Is there a second file that needs to be made or deleted in the VM that is hosting the dnsmasq service?
When I try to boot to pxe with what I currently have pxe is constantly looping