@Envy said in Help Required: Debugging PXE Boot Error on Mixed-Environment Network:

Problem: Some of our UEFI computers fail to obtain an IP address during PXE boot attempts, while others appear to continue but finally clock out with a “No configuration methods succeeded” error.

First since you have a mix environment I would start with setting up your dhcp server to send both bios and uefi boot files: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

Second the no configuration methods succeeded and not getting an IP address sounds a lot like you have the default spanning tree configured. Where you should be running one of the fast spanning tree protocols like port-fast fast-stp, rstp, mstp, or what ever your switch mfg calls it. A quick test is to put one of those cheap 5 port unmanaged network switches between the pxe booting computer and the enterprise switch. If that fixes the problem then talk to your network admins to enable one of the fast stp protocols on all network ports where you have clients that need to pxe boot. Understand this is an infrastructure issue and not specifically a fog issue.

Also make sure you have the latest version of FOG installed or at least recompile ipxe to the latest version: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

But I think I would work on the first two issues I mentioned first. Your network troubles really sound like the second issue I mentioned.

@tadziuuu Just to be clear on a few points.

The .iso / memdisk route only works for bios based computers. This will not work for uefi based computers.

With the .iso image files and the parameter block I previously provided, you get the error message about initramfs? If yes, then I suspect the fetch command is not downloading the squashfs filesystem. I copied that command over from your initial parameter block. It looks like we need to focus on that bit then.

@anothersysadmin The stuck at “iPXE initializing…” is iPXE saying that its having a problem configuring the hardware. I can see this happening on really new hardware.

I would start out with ensuing the firmware is up to date on the target computer. See if rebuilding/compiling iPXE with the latest release solves the issue. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

Understand this is a problem between iPXE, uefi firmware, and the hardware. FWIW: iPXE is created by another opensource project.

@tadziuuu Are you referring to booting bios based computers? If yes then use memdisk to load the cd iso image into memory. The one caveat here is that the iso disk must be less than 2GB in size since memdisk is a 32 bit application and there needs to be room in ram for the OS to boot from the iso image. In the same tutorial you found the parameters in your first post, search for memdisk to see what parameters you need.

After turning off the firewall on my Ubuntu VM, the install finally worked. I will close this thread and look into the correct firewall configuration.

@ice4192 Like this?
https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

i think i’ve found the solution .

i just made a new ipxemenu entry with my winpe and force via API , the default parameter to 1 to this menu entry i can find in coreobjects pxemenuoptions.

i’ll keep you informed

@george1421
Changing the settings in the default.ipxe file worked! Man this community is great! I’m going to update my documentation to make note of this so in the event we move subnets again we can tackle this same day!

@lucas942 said in Nas node storage : permission denied:

I just got to find a directory in / images on the NAS 14gb its name is: e86a64cbxxxx and this corresponds to the MAC address of my PC.
So I rename this folder “Standard”?
Because the name of my image is “Standard”

You have a few things that are wrong.

The image file should be first captured into the /images/dev/<mac_address> folder. After the image is fully uploaded to the /images/dev/<mac_address> folder the target computer logs into the FOG server (nas in your case) via FTP and issues a move command to move all of the files in /images/dev/<mac_address> to /images/<image_name>.

The screen shot of the error you see about ftp_put tells me that in the storage node configuration there is 2 fields Management Username and Management Password. The values in those fields must match the user you created on the NAS device.

@george1421
New revelations have been made. As I said I now replicated the whole setup on a local isolated network (with exception of the apparmor modifications, not necessary on a bare-metal installation).

I have my witness-computer connected to both networks with 2 seperate NICs. Only one is active at a time. In both setups I first started wireshark on the witness computer and booted a notebook into pxe.

Main network: No packets or barely some DHCP-ACKs (that were not from the booting laptop). Isolated local network: Discover -> Offer -> Request -> ACK. Laptop got an IP from the router and loaded the appropriate bootrom from the fogserver and booted from it.

Conclusion: Since the witnessing of the DHCP-packets have nothing to do with fog itself it is safe to say that there is some sort of broadcoastfiltering of the DHCP-relevant ports. The (almost) exact same installation worked in an isolated network but not on the main network.

Thank you so much, I finally know the exact cause of the problem and am able to proceed. I now have to write up a request if the networking team would be so kind to allow the broadcoasting of those port-packets to a single static IP that I own (I really hope they’ll allow that. Now that I think of it this makes total sense. If people are able to plug in their own devices into the network that behave like a DHCP-Server and then handle the IPs before the main DHCP does you are in a golden MITM-position and can intercept with the network-packets to your desire). But as far as fog goes, this is nothing from its side.

So I think I can say this is solved for the cause of “troubleshooting”. Even if my journey is not exactly at its end yet. Thanks again!

@ttrammell said in Asus ZenBook Flip UX360U - PXE Assistance Needed:

UEFI BIOS on the Zenbook still doesn’t recognize the USB-to-Ethernet adapter,

FWIW: To get this to work, you need network adapters supported by your hardwares UEFI firmware. Think of uefi as a very limited operating system. If it doesn’t have the drivers built in, then it can’t initialize the device. So if you want to pxe boot on that zenbook you need to contact the manufacturer to find out what usb network adapters are supported by the firmware … or … just boot fos from the usb stick and move on to the next problem.

@george1421 I’m 99% sure it was the suggestion of something I found on the forums a long time ago, but simply forgot.

Like I said, once everything calms down, I’m planning on rebuilding my FOG machine anyways, and blast away old images, especially since I can drop driver packs in now 🙂

@george1421 You are an absolute legend George. It works now and I was able to PXE boot from my client PC and upload it to the Hosts screen. I can view it on the network and everything is working correctly.

Thank you so much!

@rwakc well, it would be technically possible to set up a method where you could be automatically imaging any device pxe booted from the network, and set up multiple dhcp scopes on different network ports, serving out different pxe boot files with embedded scripts. that way, you’d be able to choose what image the system gets imaged with by choosing what network you plug the device into.

@Tom-Elliott Sorry I was helping someone else in a chat session so I’m now just getting back to this.

Taking Tom’s specilation that iPXE was not managing the boot files correctly on this system for some reason, I asked the OP to usb boot into FOS as a test. We’ve had to do this in the past with a few other systems that just failed to pxe boot properly. The OP was able to usb boot into FOS so that told me the kernel and the init.xz were fine. I created the boot image on Apr 6, so the kernel and inits were current of that time.

Will this process work for now for imaging, yes. Is this a long term solution, I hope not. Hopefully either a iPXE kernel update or a firmware update on the target computer will fixed the issue so that PXE booting can continue to be used in the future.

@Sebastian-Roth According to this discussion (http://serverfault.com/questions/806875/how-to-tell-isc-dhcp-correct-zone-for-reverse-zone-ddns-update) it has to do with reverse dns lookups

Through chat had @jrm run a wget to download the bzImage’s from the fogproject server. OP stated these kernels worked.

@Wirefall [Moderator note:] I’ve forked this users post since the issue is similar to the OP of this thread, but deals with a different version of FOG. You can find your post here: https://forums.fogproject.org/topic/9201/fog-will-not-boot-failed-to-get-an-ip-via-dhcp

Well… This is embarrassing.

Good news I fixed it, i get into the PXE menu now! 😄

I do have a different question now, when I click boot from hard disk in the pxe menu it doesn’t load the operating system, any ideas for that?

For the issue relating to TFTP this is what happened:

I set up a packet scan on both the DHCP and PXE server and after analyzing the packets i noticed there were two different packets sending a different option 66 and option 67. One was right pointing to the FOG server and Undionly.kpxe the other however pointed to the DHCP server. Apparently an old image deployment software was still working even though the options weren’t configure anymore. I removed these and everything worked great!