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

This can sometimes happen after you have sysprepped an machine and missed the boot menu prompt, entering the Out-of-box-experience. Trying to shutdown the device will leave the dirty bit resulting in the unclean error.

To avoid having to sysprep again, allow the device to enter OOBE again and hit shift+F10 and enter “oobe\bypassnro” at the resulting command prompt. Once you hit enter, the system will perform a clean reboot, clearing the dirty bit and allowing Fog to capture the filesystem correctly.

Hopes this helps someone else as some Dell machines are notorious for failing to get an IP from IPV4 PXE boot.

are they all in a clean shutdown state before starting?
do they already have an OS?

Just came across the same issue, did you fix it?

Based on this guide (https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue), I tried to monitor the error. One of the faulty machines stops at step seven, while the working machine continues and boots up without error.

fog_pxe_error.png

@robertkwild i have refind issues (causes a kernel panic, and my automation requires refind to work) with 1.5.10 that i haven’t been able to work around - i’m still sadly on 1.5.9 until i can get it figured out. That’s probably going to be my next forum post after hopefully getting this issue sorted.

i’m glad to see that i’m not the only one having this problem though…

@robertkwild I’m suspecting there may have been a php module update that FTP was working similarly to a found issue in 1.6 and they finally addressed that. I apologize for not thinking of it sooner and glad it’s working. To my knowledge, we didn’t change anything regarding the Folder/File issue, so much appreciated in letting us know it’s working for you now.

@tian I’ve got exactly the same problem. The initial 10 queue items complete, but the next batch won’t start. I have to click the lightning bolt icon in the task list to force it to start. Am running up to date FOG software on a fully patched Ubuntu server.

Finally , @Tom-Elliott

Reinstallation of fog solved the problem . I think the issue was linked to the fogproject account. This issue can be closed.

@infotech_22 Generally speaking, if you do setupcomplete.com, you should completely disable the FOGService as re-enable it as the final step of the setupcomplete.com script.

The reason:

FOGService will attempt to start up and perform its actions alongside anything else that’s occurring. Generally, when the system is setup and running just fine, things are okay because there’s no interactions, but when you pair it with the OOBE configuration stuff, where it could be changing ini’s and Registry thigns, then the FOG Client is saying “Hey restart to change the name and join the domain” or “Hey restart because I completed installing this Snapin” or whatever else may be going on, it can leave your machine in an unknown and cause issues.

This isn’t something we’re able to fix in a codified manner unfortunately and we have given instructions many times to allow FOG Client while in OOBE state.

https://wiki.fogproject.org/wiki/index.php/FOG_Client#:~:text=If you plan to use,the image deployment is complete.

I don’t know if this is in the more modern Documentation, but it is in the original documentation as well.

@Mr_____T Well, I have discovered a work around. According to our consultant, the legacy wrapper message in the 1st or 2nd image was kinda the key. the X360 has no wired nic port and the usb nic adabter is recognized as a legacy booting device. But the unit only boots efi. I followed this link for starters:

Kernel runtime parameter:

Next I added the MAC addresses from each usb dongle I have available. Then, from the fog web interface:

list all hosts
Select the host
Basic Tasks tab
Deploy tab
Task (I first checked debug and followed the bread crumbs no issues)
Imaging commenced.

This is quite a bit more work than I was hoping to do just to image one machine. I was hoping someone out there could come out of the fog (pun intended) and provide some feedback.

So this is not solved. But a work around that does. If you got this far Tx

Not sure why I did not just start with trying a pre 6.xx.xx kernel…

Downloaded the the last 5.15.xx Linux kernel slapped it in /var/www/fog/service/ipxe/bzimage-5.15.98 updated the host kernel to bzimage-5.15.98 and BOOM 20GB/min.

Still willing to do some testing if there is anything you need from me to see if this can be fixed in 6.xx.xx.

Hello again, I conducted additional tests. In debug mode on the client, I ran network tests between the client and the fog server using the iperf server. The results do not indicate any network issues:

iperf -c 192.168.25.11 ------------------------------------------------------------ Client connecting to 192.168.25.11, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 1] local 192.168.25.49 port 35204 connected with 192.168.25.11 port 5001 (icwnd/mss/irtt= 14/1448/924) [ ID] Interval Transfer Bandwidth [ 1] 0.00-10.02 sec 1.09 GBytes 938 Mbits/sec

I also conducted disk write tests, and they also do not indicate any issues with the disk:

bash dd if=/dev/zero of=/tmp/testfile bs=1M count=1000 status=progress 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 0.17635 s, 5.9 GB/s

I also created an uncompressed image, and it also restored slowly, with transfer speeds below 1GB/s, rather around 500-600 MB/s, which results in even lower speeds.

I changed the PXE environment boot file, set it to realtek.efi, and then changed it to snp.efi.The snp.efi visibly improved the FOS loading process, but the image restoration is still slow. Can the FOS system use a different driver during restoration than it does when operating in debug mode?