@jfernandz https://stackoverflow.com/questions/4713088/how-do-i-use-git-bisect

This is just very basic overview and probably unhelpful.

If you’re familiar with git, you can switch to different points in time (via the dev-branch) to figure out when we last knew things were good. So first, I’d suggest trying to find exactly when that would’ve been.

I’d likely start, using dev-branch as the primary “tester case”

git checkout -b dev-branch

If you haven’t already done so of course.

Then I’d put the branch at the same level as when we pushed out 1.5.10:

git checkout 081d1f4

Run your install and see if things worked, if they do:

git checkout dev-branch git bisect start git bisect bad git bisect good 081d1f4

Of course the 081d1f4 is the hash of the commit where things were good: this might or might not be the 1.5.10 release, so your mileage may very and may need some more adjustment.

You can find these hashes on https://github.com/FOGProject/fogproject/commits/dev-branch/?after=f7fd3a7a3f188b4540f089a7f38c4d368b53376c+174 using the different pages at the bottom to find a point in time, and they show the hashes on the right and side of each commit.

It will iterate through things and you just mark after each install/test what worked (as good or bad) by testing:

If it still fails, you’d run git bisect bad, if it succeeds, you would run git bisect good each iteration.

It’s tedious I know. but it will help us find the exact point things broke and hopefully from what (maybe it’s something we did, maybe something within ipxe, but gives us a starting point to test things out.)

Thanks

@Clebboii Sorry for the delay on this.
Others are having the same issue and George has something good to try. Please try this out and let us know.

@george1421 said in FOG Very Slow to Deploy Image - Lenovo Neo 50Q Gen 4:

@olivier-bonnici If you have time to test, I have an idea what maybe causing this. I just saw a video on hacking a chromebox (seemingly unrelated), and they had a similar issue with downloads being unnaturally slow but uploads were OK.

It came down to the energy efficient ethernet built into the realtek nic.

What I want you to do this this:

schedule another deployment to this hardware, before you hit the schedule task button tick the debug checkbox then schedule the task. PXE boot the target computer, it should go right into imaging, well it should drop you to a linux command prompt after several screens of text. At the linux command prompt, we need to find the name of the ethernet adapter device. Issue the following command ip a s . Look in the list for the network device that has an IP address. Write down that name for the next stel. Use the linux tool ethtool to disable ‘eee’ on the network adapter, in this case the ethernet adapter name is eno0 yours might be different, fix accordingly ethtool --set-eee eno0 eee off On success of setting green ethernet to off lets start the imaging process. Key in fog and press enter. This will place you in single step mode. You will need to press enter at each breakpoint in the code but you will be able to see the partclone screen to see if the speed has improved.

I don’t know specifically if this is your issue but its worth a shot. If it does work we can do a few things to make this a forever change, but first we need to find out if it works or not.

Updating FOG has resolved my issues. Thank you.

@rodluz said in Lenovo ThinkPad L14 Gen 5 - kernel panic:

@jflash Great! Did you use the default kernel from FOG after the update, or did you use the kernel from my repo?

I don’t try older kernel, just put new one 🙂

@Faurel ok good that looks like a clean dhcp process. It would be helpful to have the pcap file in my hand, but you want to expand the OFFER packet. The OFFER packet you can tell from the Info column.

In the packet you may need to expand the dhcp section. You should see the image similar to below. What is important is the next server IP address should point to IP address of your fog server. and boot file name should be ipxe.efi. You see in this example that the boot file name was not given, this is the error with this packet. The next server and boot file are in the ethernet header. This is the legacy bootp pxe section.

The next place you need to check is the dhcp options below. You should see dhcp options 66 which should be the IP address of the fog server and dhcp 67 should be the boot file name of ipxe.efi. In this picture this packet is also in error since the dhcp server is not sending out all of the pxe booting info. So if your offer packet looks like this you have a problem.

Screenshot from 2025-05-07 17-14-20.png

@alterak said in FOG operation in different network segments:

is there a possibility of automatic separation of locations,

I’m not sure I fully understand the question, but if you are asking can it automatically pick which location to select based on the IP address of the computer being registered. The quick answer is no, FOG doesn’t currently have that capabilities.

The bit longer answer is it could if you can be a little creative and can do a little linux bash script programming. In a nutshell, you can customize the bash script that is setup for full registration of computers. The basics of what needs to be done is covered in this tutorial: https://forums.fogproject.org/topic/14278/creating-custom-hostname-default-for-fog-man-reg

The IP address bit can come from this script: https://forums.fogproject.org/post/69725 This post is for getting the IP address to be used in a FOG postdownload script. But the concept will be the same for the fog.man.reg script.

I just want to know if it is possible. Seems like it should be, but I am having difficulty finding any information online regarding how to actually do it.

@Ced58 I use this model. It’s best to get either the official Lenovo usb c ethernet adapter or the proprietary Lenovo adapter for the special ethernet port on these. Also in the bios there’s a Mac pass through option that you want to set to internal or second Mac address. With the latest version of fog and kernel it should see that internal mac even if you share an adapter for imaging multiple of that device.

@jack_darnellits said in UEFI PXE not booting:

Running tcpdump on Ubuntu, I can see that the server is receiving requests from the client machine - but I suppose nothing is being sent back?

If your fog server and dhcp server are on the same subnet then tcpdump on your fog server should see the offer packet from the dhcp server. Inspect the offer packet to make sure in the ethernet header both next-server and boot-file values are being set correctly, also look in the dhcp options and make sure that dhcp options 66 and 67 are set correctly. I’ve seen some soho routers always point to them selves as the boot server even if your configuration says something ekse.

Additionally, i’ve used TFTP on a windows 11 vm to attempt to get the ipxe.efi file - which times out. Wireshark showed that it was receiving data packets back from the server, but would eventually time out after 8 or so attempts.

for tftp to work from a windows computer, you need to temporarily disable the windows firewall then it should work. tftp is similar to ftp where there is a command channel and a data channel. The windows firewall will block one of the channels (can’t remember which ATM).

I can get some screenshots come monday, but any suggestions would be greatly appreciated. If some more details are needed, please do let me know.

I also have a tutorial on how to start debugging this: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue you can view the pcap in wireshark to make it easier to review than just a straight tcpdump.

@CwillQCA One more thing of note. We’ve tried other adapters that we had on hand that were manufactured by other companies and they did not give us the option to PXE boot.

@olivier-bonnici If you have time to test, I have an idea what maybe causing this. I just saw a video on hacking a chromebox (seemingly unrelated), and they had a similar issue with downloads being unnaturally slow but uploads were OK.

It came down to the energy efficient ethernet built into the realtek nic.

What I want you to do this this:

schedule another deployment to this hardware, before you hit the schedule task button tick the debug checkbox then schedule the task. PXE boot the target computer, it should go right into imaging, well it should drop you to a linux command prompt after several screens of text. At the linux command prompt, we need to find the name of the ethernet adapter device. Issue the following command ip a s . Look in the list for the network device that has an IP address. Write down that name for the next stel. Use the linux tool ethtool to disable ‘eee’ on the network adapter, in this case the ethernet adapter name is eno0 yours might be different, fix accordingly ethtool --set-eee eno0 eee off On success of setting green ethernet to off lets start the imaging process. Key in fog and press enter. This will place you in single step mode. You will need to press enter at each breakpoint in the code but you will be able to see the partclone screen to see if the speed has improved.

I don’t know specifically if this is your issue but its worth a shot. If it does work we can do a few things to make this a forever change, but first we need to find out if it works or not.

@Itay1787 I just pushed a change to the dev-branch. Please try installing it again from there and let me know how it goes.

@alterak If you know how to program linux bash scripts this is possible. You will need to edit a script called fog.man.reg that is in FOS Linux (the OS that runs on the target computer to capture/deploy images). I have a tutorial on modifying that program to set a default hostname. But the concepts you need to do what you ware are listed here: https://forums.fogproject.org/topic/14278/creating-custom-hostname-default-for-fog-man-reg

Nevermind, looks like it was an error in the script itself.

I found out what’s causing the problem. The HP BIOS somehow configured the hard disk as a RAID by default. Removing the RAID, and the machine will boot to Windows after iPXE instead of looping.
Thank you for your input.

Any luck clearing up this error? Running into the same thing now setting up a separate storage node location(still local). I get this when trying to deploy an image.