@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

I was able to find a work around after running into this issue. In FOG Settings under TFTP Server update the “TFTP PXE KERNAL 32” to bzImage and “PXE BOOT IMAGE” to init.xz. I was able get thing working after that.

53e33ef4-25c1-496f-85c4-e3ff864a9aeb-image.png

@luilly23 thanks for the reply. It was a working script before and I had updated it to comment areas and operations recently and added regions within the powershell script. There were no reboot options that I can remember (fairly sure) inline in the script but will double check.

There was a reboot option on the snapin itself.

Is there any log of the fog client to server comms that could say “this caused the reboot” or just more detail. I was thinking of turning the reboot off of the snapin properties to see if it would progress.

@george1421 result!!!

i bought a HP NIC as i have a HP laptop and it works

this one if anyone is inteerested

https://www.amazon.co.uk/HP-N7P47AA-Network-DesignJet-Adapters-Black/dp/B01618WGMY?th=1

as literally star tech, ugreen, tp link, realtek or asix chipsets didnt work

@davidsontiago If you are using sysprep, include the command line option to tell sysprep to power off the computer. You have this message because when you pick shutdown from the menu, windows doesn’t actually shutdown the computer but put it into a sleep state leaving some files open that FOG sees. Sysprep will power off the computer correctly for cloning or use the following command “shutdown -s -t 0” to properly power off the source computer and close all open files.

@Tom-Elliott okay, i’ll do that.

(idk how to mark the topic as solved)