Posts made by george1421

@jack_darnellits Are you able to get IP addresses on vlan 1? If yes then dhcp is working. Your dhcp server may be doing a directed broadcast (not common) its kind of like a unicast message directly between the dhcp server and target computer. Normally dhcp servers use broadcast messages which can be detected by a monitoring computer running tcpdump/wireshark.

You may have to put the pxe booting computer on a mirrored port to see this communications.

Or as an alternative use / install dnsmasq on your fog server to give pxe booting information (only) to the computers. https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

We will typically recommend dnsmasq when you have an uneditable dhcp server or a soho router/dhcp server that will not play nice.

@jack_darnellits ok looking at the first image you posted. I see that next-server and boot-file are not set in the ethernet header these are the bootp settings, where dhcp settings are option 66 and 67. Both groups of fields need to be set because its up to the pxe boot vendor which fields they will look at so both need to be set.

Also make sure you have only one offer packet from the expected dhcp server. If you are getting more than one offer packet that means you have multiple dhcp servers responding to the dhcp DISCOVER packet.

@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.

@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:

1. schedule another deployment to this hardware, before you hit the schedule task button tick the debug checkbox then schedule the task.
2. 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.
3. 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.
4. 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
5. 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.

@stokehall From the error it appears that FOS linux is not loading correctly.

So I would have to ask:

1. What version of FOG are you using
2. What version of FOS Linux (a.k.a The Kernel) are you using? Understand this is not the kernel version of the FOG server but FOS Linu FOG Settings->Kernel update.
3. Potentially the version of iPXE because it hands off booting from the FOG iPXE menu and starts FOS Linux (bzImage/init.xz)

What I would do to try to fix this is:

1. Make sure you have the latest FOS Linux kernel installed.
2. Recompile iPXE to ensure you have the latest version, there may be a compatibility issue with older iPXE versions and the Dell bios / firmware. ref:: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe
3. Make sure FOG is at the latest release.

@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

@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.

@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.

@Faurel said in PXE over IPv4:

My DHCP server is a VM running Nutanix.

What is your dhcp server? Is it MS Windows based or something else.

Do you know how to run wireshark? I think we need to get a witness computer (a third computer not part of pxe booting). Place the wireshark computer on the same subnet as the pxe booting computer. Use the capture filter of port 67 or port 68 This capture filter will only collect pxe booting information.

What I want to focus on is the one or more DHCP OFFER packets.

1. Is there more than 1 OFFER packet?
2. Is the OFFER packet from the correct DHCP server?
3. Looking into the OFFER packet, in the packet header there are two fields one called {next-server} and {boot-file} are these fields populated?
4. Look at the dhcp options do you see options 66 and 67? Do they point to the correct values?

If you are unsure of what you are looking at, upload the file to a file share site and post the link here and I will take a look for the common issues.

@alterak Typically in your situation you would install a full fog server at the main site. Then install a FOG Storage node at the second site. Technically they perform the same roles except the full fog server has the database and the web interface. One additional caveat is that the Full fog server (or called master node) is the only FOG server that can capture images. The images created at the master node will replicate to the storage node. This is how it works by design.

One other thing that will help you is to install a FOG “Location” plugin. This way you assign fog servers and target computers to locations so the target computers will know what FOG server to get the images from.

@Faurel There are several things here.

The no valid offer received, indicates it either did not receive a dhcp packet without the next server and boot file listed or what it was given didn’t satisfy the request.

Let start with something that jumped out at me first. The pxe booting computer is being issued an 192.168.10.72 IP address (this is good so we know its receiving a reply). And your FOG server is on 192.168.3.93. That tells me they are on different subnets or you have a pretty wide network mask. Are these two devices on the same subnet?

If they are on different subnets, what is the dhcp server the workstation subnet? Is it possible you don’t have the pxe booting values set in the scope for the workstations? Or there is another dhcp server in play here?

Also make sure you don’t have white spaces around your dhcp option values I’ve seen a trailing white space on a parameter mess up dhcp too.

Lastly what device manufacturer and model is your dhcp server? Some SoHo routers will point dhcp option 66 to them even if there is a valid dhcp option 66 activated, but I don’t think that is the case here because the client is complaining about not getting any valid offers. Also on your dhcp sever make sure it issues both bootp (older) and dhcp (current) pxe booting values. These are kept in two different places in the dhcp server’s response packet.

@AxeMeAQuestion22 I see a slight contradiction, maybe in the way I read it. You have some lenovos that work and some that don’t.

It almost sounds like a usb controller issue (just a wild guess at the moment).

I just want to say this is an issue with the ipxe binaries since ipxe manages the FOG iPXE menu. This has nothing to do with FOS (yet) that would be bzImage and init.xz which haven’t been sent to the target computer at this point.

When on the ipxe menu does it accept the enter key where the arrow keys are not working?

Is this a US english keyboard? If no what language.

Just to confirm that you recompiled iPXE using the instructions you pointed to? Verify the files in tftp directory have the current date that you recompiled them.

What model/make does not work vs what make/model does work?

@Datsys On the technical side, I would install the largest ssd or nvme drive you can afford and keep everything internal. As I mentioned with the OEM image capture this is only one image and will deploy to any computer and should activate properly using the method I described. So once the image has been deployed most applications can be installed in the unattended mode, typically with command line switches. You can deploy these applications post image deployment with FOG’s snap-in system. This would still be in compliance with M$'s EULA. Basically you would adjust the computer after deployment You could even create a batch/ps file deployed by a snap-in to connect the target system to AD or make other alterations to the system, just as you might do by hand post image deployment. The extend of these post deployment activities are up to you.

I think once october hits you will have plenty of no longer useful systems hit the market so you could go to the next step of setting up local deployment servers at each customer.

@Datsys You have both a technical and legal question in your post that will require a fire dance to navigate well.

On the technical side, it is possible to configure FOG in a mobile deployment server mode. Whereas you can have FOG loaded on a portable computer and take it from site to site to deploy images. Its best if you use onboard storage for the images but it would be possible to use a portable usb drive but your downloading performance would be not good because of the bandwidth. If you used a high speed usb-c attached drive then performance would compare to onboard storage. One issue I see is that to properly network boot target computer for imaging you will need certain network infrastructure changes to make it work. This is modifying your dhcp server to send out the boot server (FOG server) ip address and boot file to load. While the fog server is on site this will work perfectly, if the fog server is at a different site not so much. You can mask this issue by installing dnsmasq on the mobile deployment server so that only the pxe boot information is sent out while the fog server is on site. This can also be problematic, but it is a workable solution.

The MS Windows/legal issue is a bit more complicated. For OEM licensed computers you are not allowed to create a golden image (customized image with additional software loaded) and then capture and deploy it to multiple computer. The EULA requires a volume license key for this. You can deploy images only in the OEM format and then after that is deployed add on custom software on top. To be able to deploy an OEM image (legally) You can either use FOG to share the ISO image to the target computer, or what I’ve done in the past is take a development machine and install Windows 11 on it, but only to the point of the first reboot. You MUST stop the system from booting on that first reboot. That first reboot is the transition from WinPE environment to the Windows Setup/OOBE process. Now capture that image at the first reboot and deploy with FOG. This is still inline with the OEM EULA because you are not altering the image only cloning it during the middle of installation. When you deploy the image to computer #2 WinSetup/OOBE will continue to run. Now at the end use FOG to install custom applications and your done.

I can tell you getting a VLK key and image is a much simpler solution. I don’t know what M$ current licensing is, but it use to be you only need to purchase 1 VLK key for all of the company’s computers to use the VLK key. You needed 5 licenses to reach the minimum order so for small companies that had a windows server and windows workstations we would purchase 1 VLK key and 4 widows servers client connection licenses, cause you can always use server connection licenses. Just let me repeat I don’t know what MS current licensing model is so this may be old information.

Just to wrap up:
Can you create a mobile FOG deployment server? Yes. You will need to be really familiar with Linux to do this though.
Can you repurpose all of these unused windows 10 computers as FOG servers and leave then connected to the customer’s network, Yes (a bit better idea).
Can you deploy Windows 11 with FOG, yes (until MS break this too).

@AxeMeAQuestion22 What hardware has this issue? Is it one model/manufacturer, all models/manufacturer?

Is the device a laptop or desktop? If laptop does using an external keyboard plugged directly into the laptop work?

What language is this keyboard?

I have to think there is something unique with this hardware that is causing a keyboard issue with ipxe.

This tutorial will give you a good general overview. https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

Since you are talking XP, then you are also meaning bios firmware. For bios you can use a utility called memdisk.

https://forums.fogproject.org/post/142041 step #18. The memdisk program is only supported under a bios based computer. If you have uefi there is a different process. There are some limitations with bios mode, your iso file MUST be less than 2GB, this is a limitation of a 32 bit bios.

@pilipp_edv ok what happens after boot.php runs?

While there is some extra text here because it looks like you have multiple network adapters in this lenovo, every thing looks good up to the call to boot.php (this tells me ipxe can reach the network because it loads default.ipxe).

I do see you are attempting to call https. Did you setup https correctly on your fog server? Did you compile the matching certificate into ipxe? I have done neither so I can’t give you exact steps, but I can tell you the certificate inside ipxe and on the apache server need to match.

@aurfalien If you are still on this quest. What we would need is the hardware id of this network adapter. You can get this from windows in the device manager. We would need the vend and device IDs.

If in linux then use lspci -nn to get the device IDs. They will be 2 sets of 4 character hex numbers within the square brackets separated by a colon. i.e. [8086:1b4e].

With that code we can see if there are standard linux kernel drivers for this network adapter.

@Mikeee89 that target computer should not attempt to download the ipxe default autoexec.ipxe file.

The first two tftp requests are normal. The first tftp request just asks for the file size then the download begins. The third request is what I might expect from an ipxe file not from the fog project. The fog project ipxe boot loader would ask for default.ipxe file not autoexec.ipxe (ipxe default file). autoexec.ipxe doesn’t exist on the fog server.

So while you are in the pcap look to see what dhcp server told the client computer. Where did it get the ipxe.efi file from (server). Was it your expected dhcp server that responded to the target computer or do you have 2 dhcp servers giving out different information?

@MichaelPower said in FOG & iPXE Anywhere - issues from boot menu:

Just wondering if a working bzImage I can use that boots under Secure Boot?

The issue is exactly that. bzImage is not signed so the uefi firmware will not boot it. That is the root of the issue. You could self sign ipxe and bzImage but then you will need to update the certificates in each computer to include your self signed certificate. Its possible but it is quite a bit of work to get it all setup.