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

@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

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!

This thread is quite old. Just here to mark it solved. I did manage to set my isp’s router as the dhcp server and successfully captured an image.
Thanks for all your suggestions and help.

@Tom-Elliott said in Capture UEFI image on hyper-v VM:

6.1.89

Thanks, this worked for me.

When tasking a host, I’d get the same as @Baessens (Hyper-V).

I went to kernel update and installed 6.1.89 as per Tom’s suggestion and I was able to get past and into image deployment!

@cjiwonder Well this is the strangest pcap that I’ve seen in a while. I finally found a uefi computer pxe booting at 8.3 seconds (you have a very active dhcp network). And the request is from 192.168.200.1.

Your dhcp server is telling the client to get ipxe.efi from 192.168.200.3. Is that your fog server? The dhcp transaction looks normal and from the dhcp side should work.

It looks like you used wireshark on the same subnet as your dhcp server? I would have expected to see broadcast messages from the pxe booting computers instead of unicast messages between the routers and dhcp server. That’s OK because we now know that the dhcp server is sending out the right boot file information (assuming that 200.3 is your fog server). If you would have used the tcpdump command from the fog server we could/should have see the target computer requesting the file to download. That would tell us if the file was actually being sent to the pxe booting computer. But from the dhcp side it looks good.

@Tom-Elliott
I could send you any log-info you guide me.
Too bad no one could help this problem.
I had so time consuming setting up this great project.
Do you might now anyone else i could send a message maybe?A remote session somehow?
Thanks for the effort anyway.

I had a problem when capturing an image when the computer was in legacy mode, when it was in UEFI mode everything worked. Then I reinstalled FOG on PROXMOX and I didn’t check Legacy mode anymore, but now I just tested imaging in legacy mode and everything works. That’s why I thought it was somehow dependent on whether fog was installed in UEFI/Legacy mode. Topic to close then.

@Tom-Elliott Thanks for the clarification, but please let me know if I can at least somehow avoid resizing the current partitions (especially boot partition), such as by checking Multiple Partition Image - Single Disk (Not Resizable) - (2)?

Hello,
I have a prod server and a test server
To differentiate them, I would lid like to change the default “blue theme” to a green theme.
Which lines should I modifi in de fog.css files ?

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

?

@kentasmith Try changing your DHCP option 67 to another one of the boot files available (link below). We had this error and this resolved it. Think changing it to ipxe.kpxe instead of undionly.kpxe helped.

https://docs.fogproject.org/en/latest/installation/network-setup/dhcp-server-settings/#option-67

@george1421 said in tftp client targetting the wrong server [dhcp relay, kea, option 66]:

@nec Good find, but I would also say that you are missing the boot-file (or whatever its called) at the pool level. That is the bootp part of the pxe booting. When you look at the pcap from the witness computer on the same subnet as the pxe booting computer. You should see both sets of values set.

OK, I get that, though I must admit that the config file I’ve shown here is sufficient and working in that particular context.

I have no idea what Kea dhcp server is but the config file looks similar to the linux standard ISC-DHCP dhcp server.

ISC started the development of Kea in 2014, ten years ago, with the objective to replace the venerable ISC-DHCPD.
As stated here, ISC has set the end-of-life of ISC-DHCPD in 2022.

(On a personal POV, it broke my heart)

@kamburta
Tom,
Sorry to take your time, you can convert from https to http by changing the information in /opt/fog/.fogsettings and running the installation again.

@george1421 I have run all test and first, there were a firewall rule that were blocking TFTP from the FOG server then after running more test, I realised that it’s not link to hardware or sofware on the server.
During test, I just changed the port on the switch next the computer to keep most of the hardware between server and client.
On same vlan I run at 450 Mbits/s (around 50 mo/s) and when I change vlan, I run at 150 Mb/s only.
And under 20 mo/s max with Windows TFTP client so I give up using it to run more tests.
Colleagues says there is not QOS but there is definitly something reducing the speed.

a06abb6b-6197-402f-ba10-c8be4fddc41a-image.png