@Tom-Elliott

Ok thanks @Tom-Elliott - that helped me. I had a script that was failing and trying to find logs for it was difficult to get a location that it could write to, that I could find after the deployment, and i couldn’t see if it was erroring or whatever… running in deploy debug was really helpful. Thanks.

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

@Mightmar Ahh , so you’ve hit a problem we see occasionally.

SNP SNPonly files, are effectively using the onboard information to drive network connectivity in the PXE environment. ipxe.efi attempts to match the device to a specific driver (usually for better performance/speed/accuracy of information)

As you might imagine, if the driver isn’t matched or not fully fleshed out, the NIC may not operate or hand off accordingly.

I think you’re right that updating the information wouldn’t have necessarily been required, but also probably wouldn’t hurt anything either (or at least shouldn’t.)

I was unable to resolve this issue with pnputil using a cmd.exe script.

I noticed that the problem was also present on another FOG installation managed by other system administrators.

I assume (perhaps wrongly) that the problem is linked to an ANSI/UTF encoding issue. If someone using another language manages to run pnputil.exe in a cmd.exe script, report it here.

I was finally able to resolve this driver deployment issue using powershell. I’m leaving a sample code (install of a driver named usbblstr.inf) in case it helps someone.

New-Item -Path "c:\" -Name "drivers" -ItemType "directory" -Force Copy-Item -Path "usb-blaster" -Destination "C:\drivers" -Recurse Start-Process -FilePath "pnputil.exe" -ArgumentList "/add-driver C:\drivers\usb-blaster\usbblstr.inf /subdirs /install" -RedirectStandardOutput "$env:tmp\usb-blaster-install.txt" -RedirectStandardError "$env:tmp\usb-blaster-err.txt"

Sincerely,

Julien

Just checking in here to Mark this as SOLVED. I had added the dev branch under a different folder. So the mix up was between the chair and the keyboard. Performed @Tom-Elliott Recommendations and reinstalled from my primary install and it is now working. trying to pxe boot MacBookPro’s. That’s another story, for another thread.

@Tom-Elliott Thank you Tom. I change the UUID’s by the devices names on the /etc/fstab on the “golden” machine before I capture a new image and I redeploy it, but apparently it doesn’t change anything

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?

ok, got it.

My storage pool had the other IP address, once I changed the IP of the storage pool to same subnet has the machine I am trying to clone, it went smoothly.

It is now copying at 257MB/min… is that good ?

@george1421 Gotcha. Thanks for the reply. I’ll post a picture of the error when I’m able to get back to testing next week.

@Tom-Elliott

Yeah, this was my suspicion. I see both sides of it too. Sounds like I’ll have to either super simplify some of my install scripts and make some sacrifices or figure out another solution.

I appriciate the response and confirmation!

@george1421 Hi,

Thanks for your reply. Its strange. I am working with (almost exclusively) early 2012 hardware. My older Imacs 2009-2011 afaict pxe boot fine image with FOG w/o issue. The problem comes along when, I try to image our macbooks. They display different levels of progress before they flat out hang. I had one mbpx,y I’m almost sure it was a 3rd gen intel just can’t find it right now. I may be being processed to go out the door to our clients.

Yes the 2019 verison of ipxe was executed from a boot of clonezill 3.1.x the version I would attempt to boot from ventory stick or from an imaged usb stick would display an error regarding not having efi capability and/or hang or return to the ventoy menu. If I just let them be long enough the MBP would just restart.

So I did attempted to roll my own and ran into the same problem with the oobox downloadable iso/zip file. Hang… I am researching w/o much success with how clonezilla compiled their ipxe menu entry or how to just plain add efi capability to ipxe.iso/zip and burn it to a usb stick. I just am not knowledable enough to formulate a good question or find what I am looking for (cause I don’t know:))

So thanks again for your reply. I have a large donations of older MBP’s coming just before the holidays and I would lik to be able to make it rain.

Regards,

@azm9s
In general, it didn’t work.
it doesn’t add it to the domain, that’s all.
Either I did something wrong.
or I have configured something wrong in the settings.

Hello, it looks something is wrong with you backend.
Are you able to open from the browser:

http://192.168.1.22/fog/service/ipxe/boot.php http://192.168.1.22/fog/service/ipxe/bzImage

?

@george1421 No luck, could you please have a remote session at your convenient time?

@COE Typically if the permissions on the /images directory get messed up you can reinstall FOG and it will fix the permissions.

If you run the chmod 777 /images that will make the directory world writable but not the existing files / folders under that directory. If you use chmod -R 777 /images it will change everything under that directory to world writable.

But before you do that, the linux user fogproject should have read write access to /images. The password for that user is found in the hidden file /opt/fog/.fogsettings That is the user account fog uses to move files around while imaging.