@Tauric said in TFTP Timeout:

(and took less than 10 minutes lol)

Well I was taking into account for slow speeds between keyboard and chair…
Glad you have it worked out. DNSMASQ should work flawlessly in your environment.

@luisgmarinr I guess the not so obvious question would be, where did you get the win10.pxe boot loader? That is not one from FOG install.

The obvious question would be is 10.0.2.4 the IP address of your fog server?

@lmcfog OK lets start debugging this with this:

1. Schedule a capture task on the source computer, but before you hit the schedule task button tick the debug checkbox. Now schedule the capture task.
2. PXE boot the target computer, after several screens of text you need to clear with the enter key you will be dropped to the FOS Linux command line.
   (side bar: If you want a bit easier time debugging in the FOS console do this.
   a. key in ip a s and get the IP address of the network interface. It should be something valid for your dhcp address range.
   b. Give root a password, it can be any password since it will be reset when the FOS session reboots. Make it simple like hello. Use passwd root to assign the password.
   c. Now you can connect to the FOS linux session from your desktop linux computer (use ssh) or from a windows computer using putty. Connect to the IP address you found in step a. Login with user root and the password you assigned in step b.
   /sidebar)
3. Key in the following commands and post the results here.
   df -h
lsblk
cat /proc/cmdline

Also in the fog webui, in the host definition for this target computer post a snapshot of how you have this specific hardware settings configured.
Lets see how that hardware is configured.

@lmcfog Linux is a little different than windows. /dev/sda is the first physical hard drive on the computer, if you had a second physical drive that would be listed as /dev/sdb

Now the partitions are listed after the device, so /dev/sda2 is the 2nd partition on the first disk. If its only capturing /dev/sda2 then you might have the system configured to only capture a single partition, where you would normally have the configuration to capture all partitions on a single disk. Or pick in the host configuration multiple disks multiple partitions for capture if you want to clone all physical hard drives on the target computer.

Is there a specific problem or was this just a general question.

@Tauric The question about editing the pcap, I’ve seen some people mask info in the pcap thinking about privacy, but that just adds confusion, like the unprintable characters. I thought the unprintable characters were the results of hand editing the pcap file.

The advantage of going the dnsmasq route on the fog server is if the fog server isn’t running you have nothing issues pxe boot into. If you go the dnsmasq route remote the pxe boot information in your router so it doesn’t confuse things when the fog server is offline

@Tauric ok I see a whole lot of issues here. Let me ask you did you mask out any data in the pcap?

In the ethernet header (bootp protocol) the boot-file field is blank (should be ipxe.efi). The next server points to 192.168.0.254 not 0.33) Looking at the dhcp part, dhcp option 66 (should be boot server IP) is an unpritable character. DHCP option 67 is ipxe.efi but its not terminated with an end of string character 0x00, it ends the string with 0xFF. For background both bootp and dhcp options need to be set because its up to the pxe rom writer to pick if they want to boot using bootp (older protocol) or dhcp. The issue here is with your dhcp server giving your target computers bad info.

Since you are using a SOHO router, we see them not exactly place nice with pxe booting.

My recommendation is if you can’t fix your dhcp server easily then forgo using it and install dnsmasq on your fog server. It will take about 10 minutes as well as support dynamic pxe booting (bios/uefi). DNSMASQ in this configuration will not issue IP address, but only pxe boot into. https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server?_=1698421239631

@Tauric On the windows box, make sure you disable the firewall since tftp uses 2 network ports like ftp does, if you are trying to make a comparative test.

Since you seem confident with tcpdump. Lets follow this tutorial to get a pcap from the FOG server. This will show us the dhcp process as well as the tftp process at the end. It should give us a good picture of what is going on. Capture the pcap and upload it to a file share site and I will take a look at it. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue?_=1698421239623 I’ll need the complete pcap since the screen shots don’t show the complete details and there are a many exceptions to list.

@Tom-Elliott We’ve also seen some strange interaction between green ethernet settings on some switches and these new (at the time) l219-v network adapters too. But I really don’t think that fits here since I can assume they use this switch model across their campus.

@plegrand said in intel I219-v big problem:

The only problem is this room with these network cards.

I find it suspicious why only these network cards have a problem. The problem doesn’t sound specific to FOG, but more on the dhcp layer. The next step I would say is to get a pcap from a witness computer on the same subnet and from the same switch to see what is “flying down the wire” so to speak. It would be interesting to get a pcap of a working and non-working computer in the same lab, off the same switch.

FWIW, dhcp snooping is dhcp specific to limit/restrict the impact of rogue dhcp servers. igmp snooping is related to mulicasting and publishers and subscribers.

@plegrand Is the dhcp server on the same subnet as the pxe booting computers?

Is the dhcp server running on the fog server?

Is there by chance a second dhcp server on this network?

Does this switch have dhcp snoopling enabled?

Running wireshark or using tcpdump on that network with the capture filter of port 67 or port 68 or us the display filter of bootp should show you the DORA process (Discover, Offer, Request, Ack/nak). The dhcp server might either not be responding in a timely manner or you have more than one dhcp server on your subnet. I haven’t seen this type of error before so there is something unique going on with this network.

@stevem1978 First thing I would check is to make sure secure boot is disabled.

The next thing is to make sure you have the dhcp scope enabled.

It kind of sounds like its not getting the dhcp pxe boot info from your dhcp server.
If all else fails load wireshark on a witness computer. Put that witness computer on the same subnet as the pxe booting computer. For wireshark configure a capture filter of port 67 or port 68 or use a display filter of bootp. Start wireshark then pxe boot the target computer until it fails, then stop wireshark.

You should see 4 packs (Discover, Offer, Request, Ack/nack). What will be interesting if you have more than one OFFER packet, you would typically only have one from the dhcp server. Look at the offer packet. Make sure in the dhcp header the fields next-server and boot-file to make sure they contain the expected values. Then look down in the dhcp options section at options 66 and 67. Make sure that both sets of fields have the proper values.

@Tanguy Lets first identify that the database engine is at fault here. Lets just do the first step in the tutorial.

SELECT TABLE_NAME,ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'fog' and ENGINE = 'MyISAM';

If the query responds with MyISAM then this is the problem. If it responds with INNODB, then lets discuss.

If its the data engine, you can make this change while the system is up and running, no need to schedule downtime.

@Tanguy OK here is what I’m thinking. We had a performance issue a while ago with earlier releases of FOG, where the default sql server data engine was being used instead of a higher performance version.

The conditions were > 300 computers with the fog client installed. When you looked at top and sorted by P cpu there would be many php-fpm services running as well as high CPU usage on mariadb. This is because the default ISAM db engine uses table style locking on an update, where INNODB uses row level locking. Switching over to INNODB resolved this issue. I don’t remember which version of FOG is when the Devs switched over to using innodb by default. I did write a tutorial on how to update your db design that you might want to use to see if you are still using the ISAM engine or the INNODB database engine. If you are using the INNODB engine, then we will need to debug this issue since its something different than what we’ve seen before.
https://forums.fogproject.org/topic/16099/configure-fog-database-to-use-innodb-engine?_=1698321484681

@Tanguy How many client computers do you have in your environment that have the fog client installed on them?

@zaboxmaster Another opiton might be to access the windows registry to read out the version. Within the FOG OS (FOS) linux there is the linux reged program. That can be used to read/edit the windows registry.

Below is an example from one of my tutorials on post install scripts to update a registry key. That is only meant to show you what is needed to make the program work.

egfile=“/ntfs/Windows/System32/config/SOFTWARE”
key=“\Microsoft\Windows\CurrentVersion\DevicePath”
devpath=“%SystemRoot%\DRV;%SystemRoot%\inf;”;
reged -e “$regfile” &>/dev/null <<EOFREG
ed $key

The question is how would I go about doing this if at all possible?
Where would the best place be to run it from? FOG.MAN.REG ???
Is the Windows mounted at all during registration?

Is it possible, yes

Best place, yes probably a customized version of fog.man.reg (I have a tutorial on how to slide an updated version of that into FOS Linux at deploy time). To make the inventory also query the target OS.

No windows os partition is not mounted during inventory. For FOG inventory its not needed. BUT I have a tutorial on how to find and mount the partition during a post install script for driver injection that you can use as the basis for the inventory process.

@boros

I want to transfer the “Gold” Images from the server in the other site. Can I just copy and paste the Images Folder from from the other Linux Machine?

The short answer is yes, but there is something you need to know.

FOG Images are made up of two components. The first is the raw data files that are kept in /images directory on your fog server. The second part is the metadata kept in the database. You need both to make the image functional. You can copy the files over by hand, but you will need to either recreate the metadata on the target system by hand (not a difficult task) or export the the image definitions from the source computer and import them on the destination computer

Now one other tidbit that is not supported by the developers, but it works. If on your master server you add the remote fog server as a storage node. The main fog server will be a master node and the remote server is a storage node (just in the context of this configuration), the master node will copy any image marked as exportable all storage nodes in its storage group. This will get the raw images over to the target system using the standard fog image replication. But the thing it doesn’t do is copy over the image definitions. You will need to do this using the export and import method, or by manually creating the image definitions by hand. Using this method you can have golden images pushed out by HQ and each site will still be able to create their own golden images too.

@boros Ok there are two things here.

On installing fog there are 3 phases. 1. Start the FOG installer from the linux CLI and answer the preinstall questions. 2. GO to the Web UI and execute the action there to create/update the database. 3. Return back to the fog server console CLI and complete the installation. If you miss/skip part 3 you won’t have the required services installed. The /tftpboot directory will be blank. There won’t be any FOS linux os (bzImage and init.xz) in /var/www/html/fog/service/ipxe directory. The quick fix for this is to simply rerun the installer and completing all three steps.

The second one you have to remember is that WDS uses a netboot service, which is akin to proxydhcp. ProxyDHCP overrides the dhcp settings provided by the dhcp server for netbooting (options 66 and 67). A quick check is to have a witness computer on the same subnet as the pxe booting computer. Run wireshark on that witness computer using the capture filter of port 67 or port 68 or use display filter of bootp. Look to see if you are getting multiple OFFER packets. If only one look into the one OFFER packet to see if dhcp option 60 is present. That signals a proxydhcp packet. If it exists that tells the client to contact the dhcp server after the dhcp exchange for pxe boot information on port 4011.

@Eliza In the FOG web user interface. In the FOG menu FOG Configuration and then along the left menu Select Kernel update.

@Eliza OK on tuesday I want you to update the FOS linux kernel. Its under Fog Configuration -> Kernel Update. My guess is that you have an older version of the linux kernel. The latest version of the FOS linux kernel is 6.2, If you have version 4.19 or 5.5 it might be to old for your new hardware.

@Eliza Can you post a picture of the error message when you try to upload your image? I don’t understand why 10th generation cpu causes a problem.

I need to ask what version of FOG and what version of the FOS Linux kernel are you using?