@tahitiju said in Multicast is very slow:

I try to deploy an image to some PCs but performance is very low (2MB/min) using multicast.
For the purpose of the test, FOG server (1Gb NIC), clients (1Gb NIC) and dhcp are connected together using a Linksys Switch ( 16 x 1Gb ports / unmanaged) .
Using unicast, performance seems normal (~1,5GB/min deploying 14 PCs).

A few things jump out at me with this. Multicasting can be very taxing on inexpensive network hardware. When you are getting 2MB/min how many systems are you multicasting to? Do you get the same performance when multcasting to 1 or 2 machines?

Multicast imaging moves at the speed of the slowest computer in the mcast group.

1,5GB/min is on the slow end of the scale. On a well managed 1GbE network, imaging to current hardware, I would expect about 6GB/min. If put your fog server on 10GbE network I would expect about 13GB/min. I’m only pointing it out that there might be something in your network infrastructure that is slowing things down.

A 1GbE network link will saturate with 3 simultaneous unicast deployments.

The FOG performance numbers displayed on the target computer are a composite number of how fast the fog server can pull the image off the disk, send it over the next, the client receiving the image, expanding it in memory and then writing it to disk. Any one component that is slow will impact the overall performance score.

@pastorn Are the vms on the same ip subnet as the FOG server? Multicasting packets won’t normally cross a router with a special configuration.

@Enigma yes same method as before.

@Enigma I would start with example #1 from that url. You will need to update the subnet, netmask range values so its appropriate for your isolated network. Anywhere you see the default 192.168.1.x you need to update so its appropriate for your imaging network.

@koenr said in Dell Latitude 3500:

class “LATITIDE-3340” {
match if substring(option vendor-class-identifier, 0, 32) = “PXEClient:Arch:00007:UNDI:003016”;
filename “realtek.efi”;
}

This will cause other systems to fail. There is nothing unique about “PXEClient:Arch:00007:UNDI:003016” multiple hardware will match.

Also order that the item appears in the list is important. The first match wins rule. For Dells the UUID field of the ethernet header should be unique within a model. If you use wireshark you can pick up the uuid of the pxe booting computer in dhcp option 97. You can tell if you have the right value because the first 4 characters spell DELL in reverse in ascii.

The other option if you only have a few of these devices is to use mac address matching to target specific computers with specific boot loaders.

@Enigma ok so how did you add dhcp services to your fog server (a blank dhcp config file would do exactly what you are seeing. ISCDHCP listening but not responding to any requests)? Did you add dhcp services when you installed FOG? Did you add the isc-dhcp server after fog was installed from your repo?

So you’ll probably ask what goes in that file? Look at this example: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Example_1 The dhcp pool will probably need to be updated to match the subnet of your dedicated imaging network.

@Kusa555 To add on to what Tom said just remember this,

ipxe.{efi or kpxe} contains all of the common network drivers much like linux or windows OS’ contains all of the common network drivers already built in.

The undionly.kpxe only contains 1 network driver for the undi network protocol that is built into each bios network adapter’s firmware.
The snp.efi and snponly.efi only contain 1 network driver for the snp network protocol built into each uefi network adapter’s firmware.

Boot loaders that end in .pxe, .kpxe, .kkpxe are bios boot loaders
Boot loaders that end in .efi are uefi boot loaders

So what should you use?

For bios, undionly.kpxe
For older uefi system (older than 4 years) use ipxe.efi.
For current uefi systems you may have better utility from snp.efi

@typotony Hi, I can say much of the API because I don’t use it, but it seems from the quick docs on it there is a image delete function https://news.fogproject.org/simplified-api-documentation/

/fog/image/<IDOFOBJECT>/delete

A forum member @JJ-Fullmer has more skills with the API than I do.

@mdxlp Let me tell you how I debug post install scripts. At the top of the post install script I insert an echo with something notable so you can quickly identify it. And then right after insert a debugPause; command.

Now schedule a deploy task to your target computer, but before you hit the schedule task button tick the debug checkbox. Now schedule the deployment task.

PXE boot the target computer and it should drop you to a linux command prompt after a few screens of text you need to clear with the enter key. This is debug mode.

To start the debugging process in single step mode key in fog and press enter.

{sidebar} If you want to remote debug your post install script get the current ip address of the target computer with ip a s and then set root’s password on the target computer with passwd. Set it to something simple like hello. Now you can connect to the target computer using ssh or putty from a remote computer. Key in fog to start the single step imaging process {/sidebar}

The deployment script will stop at each debugPause command. Keep pressing enter until you see your echo statement you put at the beginning of the post install script. At this time if you press ctrl-c you can exit the deployment script. This will give you a command shell with all of the proper environment variables you can inspect with the set command. Running the curl command from my previous post should produce all of the fog variables.

@mdxlp You may need to add this code to your fog post install script to load in all of the variables that fog has to offer into your post install script.

if [[ ! -z $mac ]]; then
    curl -A "" -Lkso /tmp/hinfo.sh ${web}/service/hostinfo.php -d "mac=$mac" 
    if [[ -f /tmp/hinfo.sh ]]; then
        . /tmp/hinfo.sh
    fi
fi

This basically makes a call to the fog server to collect the host info for that specific mac address. then it loads the hinfo.sh script created by the php program.

FOG is linux based, and linux can not step into the windows realm, so there is no equivalent linux command for netdom that is windows only.

@SebastianWolf What version of FOG are you running?
Second bit is have you tried to rebuild ipxe with the latest source code: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe?_=1687483137078 sometimes it does take the iPXE developers (not related to the fog project developers) a little bit of time to support really new kit. So there may be updates to iPXE after the FOG developers released the latest version. So lets start with iPXE rebuild if you are never seeing the iPXE banner on these computers.

If iPXE is failing for you we do have a method to usb boot into FOG, you lose some capabilities but it will image correctly once you register the target computer with FOG. So you guys are not dead in the water if iPXE doesn’t support your hardware just yet.

@C-Franklin Manually register this target computer. You will need the mac address of the target computer then add a new host with that mac address. Now schedule a deployment, but before you hit the submit button tick the debug check box then submit the job.

Now pxe boot the target computer, it should go into imaging right away (I want to see if iPXE is detecting the mac address). If it goes into imaging after several screens of text tat you need to clear with the enter key you will be dropped the FOS Linux command prompt you may still see the no viable mac address error, but that’s OK for now.

Once at the FOS linux command prompt I want you to key in the following commands. After the last command it keyed in take a clear picture of the screen and post the results to this thread.

uname -a
lspci -nn | grep -i net
grep -i firmware /var/log/syslog

I can never remember of its /var/log/syslog or /var/log/messages so YMMV.

On this target computer find one of the same model that has windows installed. In the device manager check this nic and collect the hardware ID of the nic. We will need the vendor and device IDs in case the lspci command doesn’t return anything usable.

@rhromyko said in new version e2fsck ?:

I get the error message when I try to create an Ubuntu 23.04 image

Sorry to ask the question again, but your response can be read a few different ways. I think I understand what you are doing with FOG but I want to be sure.

1. You are using FOG to PXE boot into some live image of ubuntu?
2. You are either capturing or deploying a golden image from a source computer. You are getting this e2fsck error wile imaging a computer (using fog as it was designed for system cloning) with FOG.

Remember here we are trying to understand where the error is by your words explaining what you are doing at the time the error is made.

@rhromyko This is probably related to the latest versions of Ubuntu and Debian, I’m a bit surprised that 22.04 has the issue though. I’m suspecting that FOS Linux doesn’t have the 1.47 version installed. Is the error happening during imaging or is it when you live boot Ubuntu?

As Tom mentioned the term “PXE OS” could be confusing the issue. Let us know exactly where in the process you are getting this error.

@Enigma Well it look like I forgot to hit submit earlier when I responded. Looks like the dhcp server is up and running and listening on port 67. So that is the first half of getting things to boot.

I think the next step is to configure the fog server to capture a pxe boot packet to see if there are any other actors involved. Here are the steps needed to configure tcpdump on the fog server to capture the pxe booting process.
https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue?_=1687300270627

Other things I’ve seen cause pxe booting issues.
If dhcp snooping is enabled on your network to only allow dhcp packets to get to the defined dhcp server and that dhcp server is not the FOG server.
If you have more than one dhcp server on your subnet and the other dhcp server responds before the fog server.
You have a proxy dhcp server configured on your network
Your fog server is running as a VM on a vm host server that doesn’t have the promiscuous network mode enabled.

Most of these questions will be answered with the pcap. Once you collect the pcap upload it to a file share site and share it as public read only. Then either post the link here or use the fog forum chat and DM me the link. I will take a look and let you know what we found.

@Enigma ok on the fog server linux console. Key in the following command netstat -an | grep :67 That should return a line like 0.0.0.0:67 This will show if the dhcp server is running on the fog server. You can also run this command ps aux| grep dhcp to see if the isc-dhcp server is running in memory. Lets confirm that dhcp is functioning on the fog server

@Florent for the 64 bit versions of uefi, you would replace ipxe.efi with snp.efi or snponly.efi in the config file and then restart the dns server.

The difference between snp.efi and snponly.efi is that the snponly.efi will only init the network interface where the snponly.efi was downloaded from, where the snp.efi will init (and try to boot from) all interfaces in the target computer.

@smazzola What version of FOG are you using?
What version of the FOS Linux “Kernel” are you running?
What error are you getting on the target computer? Can you get a screen shot of the error to provide context?

@Enigma Your post is missing enough info to help.

Is 192.168.107.x an isolated network?
Is there an existing dhcp server on this subnet?
What error are you getting on the client computer?

@wass Since all of the boot loaders you mentioned are bios boot loaders and you are seeing the no configuration methods succeeded it sounds like the computer is in bios mode. Its strange that iPXE and bios mode computers are not able to configure the interface. For bios the boot loaders undionly.kpxe or ipxe.kpxe should work on 99.8% of all computers. Does this computer have multiple nic cards?