@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 George’s mention of using a post install script to do it is more advanced but very worth the effort. Having it domain joined via sysprep specialize simplifies things in the long run.
That being said, you’re probably misunderstooding groups, because they’re a little confusing. Groups in Fog do not dynamically update the OU of the host members, but it can be used to set the OU in bulk on members. There is a plugin to change the behavior of groups if you want, but I’d try it the normal way first.
But if you set the OU on the host, then when it joins the domain via the fog client, it will be in that OU. It will not move a host to a different OU, unless you do something like manually leave the domain and change the computer name and then the fog service will rename the computer back to what it is in fog and then join the domain in the set OU.

I personally use a post install script now that grabs the OU from to host and Injects that into my unattend file. I believe I’ve posted some examples in the past. If I remember tomorrow when I’m at a computer and not a phone, I’ll link them.

@John-L-Clark what version of fog are you running?
I would also suggest enabling the Mac address pass through.
You could also try an older ipxe file

@argylega have you restarted the Mariadb and apache services, or the whole server?
I also assume you mean you can’t login to the website. Is there anything in the apache error log?