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

@lucancurtismahoney First let me start with the yada-yada-yada. Imaging over wifi is not supported by the developers of FOG. Imaging over wifi has its use cases but also is not advised because wifi is a shared resource and your entire wifi network will suffer if you try to image over wifi. You would be better served to get a supported (by the manufacturer) usb ethernet adapter and pxe boot over that.

With that said it might be possible to image over wifi if FOS is configured in an (unsupported) way. It will require a custom FOS Linux kernel and some tweaks to the virtual hard drive to add in the needed bits to configure wifi.

Below is a FOG USB debug image that contains a modified bzImage and init.xz files. Use rufus to burn to a 1GB usb drive. The image is less than 500MB so don’t waste a large usb on this boot image.

Understand this boot image WILL NOT WORK out of the box. We will use this for debugging your network adapter. Many network adapters need specific drivers to work with a linux kernel. We will find out what that firmware is with this debug usb.

1. Use rufus to write the image file to the usb drive.
2. Edit the grub.cfg file with notepad++ (not windows notepad) its located in the /boot/grub directory. At the top set the IP address of your fog server, and half way down the variable add in your wifi ssid and password. Remove the curly braces.
3. Save the config file and then take it to your target computer.
4. USB boot this image file on the target computer. You may see some error messages about networking, but that is expected.
5. After a few screens you need to clear by pressing the enter key you will be dropped to a linux command prompt.
6. See if you can see the wifi adapter with this command ip a s If you see something like wlXXXXX then the driver is loaded and you are done.
7. If you only see the loop back (lo) adapter then continue.
8. Key in the following command it will look through the startup messages for anything that mentions firmware. grep -i -e firmw /var/log/messages My bet is there will be a message from the intel wireless (iwlwifixxxxx) saying that it needs a specific firmware to load. Take a clear snapshot of the name of the firmware name with a mobile phone and post it here. I will patch the kernel with the required firmware and upload it with additional instructions.

https://drive.google.com/file/d/1psCrPVzBTvlakLkCMvhdoScAEZp1CKE6/view?usp=drive_link

@Gordon-Taylor said in ASUS NUC14RV iPXE PXE boot:

if i use a USB Stick with D:\EFI\BOOT\bootx64.efi (ipxe.efi from tftp folder) then i can get them to register and image

Start HTTP Boot over IPv4 on MAC: MACADDRESS and it just hangs here and doesn’t start iPXE
is PXE booting and HTTP Boot over IP two different things? and is this somehting i can get working.

In the first section that is good, that you can get it to image with booting from a usb drive. That means ipxe and bzImage (FOS) supports that hardware.

On the second part, yes http booting and pxe booting are two different methods. Of course http booting uses tcp over the http protocol, and pxe booting uses udp over the tftp protocol.

I don’t know how you can tell the computer what ip address and boot file to boot from. But if you copied ipxe.efi to /var/www/html/fog directory you can (should) be able to download ipxe.efi over the http protocol.

But that said those devices should be able to pxe boot. That feature will typically need to be enabled in the network configuration section of the firmware (I don’t know these computers, so I can only speak generally). The intel nics have the pxe booting firmware built in, so it should work.

Does it even look like its attempting to pxe boot and then failing over to booting over http? Does the F12 menu say anything about pxe booting (it may need to be enabled in the firmware before its displayed on the boot menu)

@Nyeine I’ve got an Orin Nano at home and an AGX at work. I’m not sure you can image them with FOG. TBH I have never tried, so it would be interesting to find out.

One comment before I get too deep into this, if you use for your dhcp server either WIndows 2016 or later or linux as your dhcp server, you can setup profiles with your dhcp server to automatically send the right ipxe boot loader based on the pxe booting computer. You won’t need to mess with the ipxe.efi files like you have. You can surely continue to do it that way, I just wanted to let you know there might be an easier way to go about it.

So you are able to pxe boot into the iPXE boot loader, as soon as you pick a menu option that is where the wheels come off, so to say. Looking at the screen shot the process is failing at the handoff between ipxe and FOS Linux (arm_Image+arm_init). Its hard to tell if its ipxe or fos linux at fault.

I have a process to create a debug usb image for x64, but I haven’t tried to create one for arm. In theory if you have a working Jetson Orin running ubuntu you should be able to follow this to create a FOS linux usb boot image: https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image In your case you don’t want to use bzImage and init.xy but use the arm_Imag… (to replace bzImage) and arm_init (to replace init.xz). The idea here is to see if you can select register from the grub menu to get FOS Linux to boot on the jetson nx. If it can then the issue is with ipxe. If it doesn’t hopefully you can debug with the usb boot image.

You may need to build a custom linux kernel for the Jetson. Just for reference https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/SD/Kernel/KernelCustomization.html

@joshua_mchugh I’m not sure if there is a good and proper way to do it but there maybe some way to go about it.

If you use an unattend.xml file that file and windows can place the computer into the proper OU. The idea is to use a post install script programmed in bash to dynamically update the unattend.xml script at deployment time. You can’t use fog group per se to do this since they are really “set groups” where the groupings are only used to bulk update parameters. But if your OU can’t be calculated you can use the user fields in the host record, and or the image name could be determined in the post install script.

I’ve got some examples of how to calculate a host name and OU based on the target IP address of the computer being imaged. This isn’t your solution but shows you what is possible in a post install script in the links below.

https://forums.fogproject.org/post/69726
https://forums.fogproject.org/post/69725

In one section of the links above it shows how to post a question at deploy time that could change how the OU path is calculated before the unattend.xml script is updated. The last tip is to use a post install script to leave bread crumbs behind so that the setupcomplete.cmd or the first run section of the unattend.xml file can find and integrate into an OU path. At one deployment we had to first set the target system’s OU to a clean OU used specifically for imaging because the OU GPOs would break OOBE/WinSetup. Once the system was fully configured we use the unattend.xml auto login and first run section to call a VBS script to read the bread crumb (info saved in a text file) to then finally move the computer to the correct OU.

None of these are proper, but as they say if all you have is a hammer, everything looks like a nail.

@tatanas Let me ask why are you renaming the host in the windows UI? Do you not know the actual name of the system at imaging time?

Second question: are you using the fog client service at all?

@Mightmar I wonder if the devs for iPXE has changed something in the ipxe source code to cause this error message about autoexec.ipxe not found. This should be supplied by the fog project add on files. I’ll take a look at the compiler to see if something has changed. You should not see this error.

Reinstalling 1.5.10 will fix the error of the latest build of iPXE. Also you mentioned about a later version of FOG. Yes you can install that over 1.5.10 without issue. It should also have updated (but not the newest version of iPXE).

@Mightmar Just a few points of info to give you.

1. iPXE is managed by a different project than the FOG Project. They have a quicker release cycle than the FOG Project so they will/may support newer hardware quicker.
2. When a specific version of FOG is released it contains the current version of iPXE at the time a specific version of FOG is released.
3. If you manually update iPXE using the following instructions: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe and then reinstall FOG 1.5.10 it will replace the updated version of iPXE created by the previous script with the version shipped with FOG 1.5.10. This is by design in case you make a change that breaks FOG you can always fix it by rerunning the FOG installer putting back the FOG files to a known good state.

So to say it another way, if you find issues with iPXE not supporting certain hardware, I would always upgrade the version of iPXE first and just remember that if you reinstall FOG it will replace the updated versions of iPXE and the FOS Linux kernel with the ones that were shipped with the current release of FOG. While I don’t know what the current release of FOG is I believe there are sub release later that 1.5.10 that fix a few discovered issues.

@alexamore90 Lets try to unpack this.

You have 3 ESXi servers connected to an unmanaged switch.

This part is a bit unclear. After deploying on a few pcs the speed dropps to 900mb/min (watch your unit of measure). Normally its up to 22GB/min (again assuming you are getting this number from partclone).

After deploying to a few PCs the speed drops. Is this simultaneous deployments or consecutive deployments the speed drops?

Unmanaged switch: So this isn’t an enterprise class switch. You may have issues with throughput on the switch itself. The aciscs might not be fast enough for the amount of data your are trying to push through. Look at the throughput listed in the technical documentation for the switch.

You didn’t mention the uplink speed from the ESXi servers to this switch. On a well managed 1GbE network you should get around 6GB/min throughput. On a well managed 10GbE network I’ve seen 13-15GB/min. So your 22GB/min seems a bit higher than expected. I can say with a physical FOG server connected via 1GbE link, I can saturate that 1GbE link with 3 concurrent image deployments. When that happens the error rate increases and the throughput drops off quote a bit.

The other thing if you are trying to do concurrent deployments with these 3 FOG servers, make sure the drives on ESXi are SSD or NVME drives and not spinning disks for performance reasons.

In the end I don’t think this is a FOG server issue specifically, rather something in the environment that is causing the speed issue.

@ALV_SUPECOLES This seems to be similar to this thread: https://forums.fogproject.org/topic/17759/ipxe-initialising-devices

In this case uefi firmware was updated then iPXE stops at initializing devices. If compiling and installing the latest version of iPXE doesn’t solve the problem then we will have to wait for either iPXE developers or Lenovo to fix the problem. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

@nicolas-moraes We have to be careful some Soho routersthe don’t behave well with pxe booting. Some will put its IP address as the boot server even if you have dhcp option 66 configured. I don’t know the edgerouter, but if there is a bootp option make sure that is turned on too.

The edgerouter is based on vyos so it should behave correctly. Make sure when you define dhcp option 66 its the IP address of the fog server and for dhcp option 67 the boot file name needs to be all lower case. Make sure you don’t have a leading or trailing white space in the name.

If you have double checked everything then get a witness computer and load wireshark on it. Make sure you setup a capture filter of port 67 or port 68 start the scanning then pxe boot the computer until you get the error message then stop scanning.

What you are looking for is the DORA sequence
Discover (sent by target computer, akin to hello world, please configure me)
Offer (sent by one or more dhcp server, I would there to be only one of these and from your edgerouter).
Request (sent by the target computer)
Ack/Nack (sent by the dhcp server)

The interesting packet will be the OFFER.

Look at the packet, there should be an ethernet header section with the following fields.
Next-Server: this should be the IP address of your fog server (this is the bootp part)
Boot-FIle: this should be the name of the ipxe file to load.

If either of those are blank some pxe clients will not boot if they look at the bootp fields.

In the dhcp options section you should see option 66 and 67 that should mirror the values in the bootp part.

@JYost well there is two ways.

1. download the git version so you have all of the bits in place and recompile it.
2. redownload the released version of the ipxe files from here: https://github.com/FOGProject/fogproject/tree/stable/packages/tftp

I think you will be better served by option 1 in the case of upgrades, but the quickest route is #2 which will download the older binaries for iPXE.

@RocksAndRolls I’m not sure how much additional help I can provide here but where it failing is at the end of the imaging process, the target system logs into the ftp server on the FOG server using the fogproject user account. That fogproject user MUST be able to rename the captured file in /images/dev from the mac address and the move the directory from /images/dev/<mac_address> to /images/<image_name>.

If you have verified you can log into the fog server via ftp as the fogproject user using the password saved in the fog ui then it has to be a permission issue on the /images directory.

The image capture process is

FOS Engine -> connects to /images/dev NFS share and creates a directory that matches it’s mac address
FOS Engine -> Uploads the disk connect as the root user (on the FOS Engine)
FOS Engine -> Connects to the FOG server as fogproject user and issues a mv command to move the directory from /images/dev/<mac_address> to /images/<image_name>
FOS Engine -> Logs out of ftp and completes the cleanup before reboot.