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!

Thanks to all who participated in this thread. I killed the switch port that someone had a Netgear router hooked up to and everything is working fine now. FOG menu is showing up. I haven’t tried pulling down an image yet, but I have a good feeling. I will do my best to up-vote the proper answers even the earlier posts questioning the possibility of multiple DHCP servers. I had a feeling one was out there, but I didn’t think it would have a such a huge impact on FOG. Again thanks everyone for all the help!

@mcgill-eus if you follow the Upgrade to Trunk instructions exactly, you’ll get Release Candidate 6. RC-7 will probably be out sometime today though and I feel it highly important to move to that when it’s out, as it fixes some issues in 6.

You are trying to boot the I.S.O. over the network. The way I recommend you do this for pxe access in your company is to extract the content of the iso to a folder of your choosing then give proper access to the folder for the fog server using the exports file. examples can be provided if im understanding what your trying to do?

Bonjour Oui c’est bien FOG 1.2.0 et c’est bien la modification initrd=$imagefile qui à fait fonctionné sur MAC ######### Hy Yes it’s good FOG 1.2.0 and it is changing initrd=$imagefile who in fact worked on MAC

Thank you all. I will update in case resolved. Take care!

@Sebastian-Roth said in Impossible to boot on PXE......: Wireshark filter bootp && tftp is great for this This has been in the wiki for some time, here: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_TFTP