@cjiwonder said in UEFI is not booting with Windows DHCP:

Already secure boot is disabled.

sorry I missed that in your first post.

What error do you see? Is iPXE even trying to boot?

The difference between ipxe.efi and snp*.efi is in the network adapter. If iPXE boots but can’t find the network interface then you are not selecting the correct version of iPXE. But if iPXE never boots (what I suspect) then there is something wrong with the mechanics of getting the uefi boot file to the target computer. What error does the computer screen say? Something about “NBF”?

@Tom-Elliott
There is not anywhere on tests connection failed.
Do you need further any logs maybe or info for sort this out?
THanks

@JJ-Fullmer
Here is my csv
d78f9374-a2cc-47ed-954f-352d3e853e9b-image.png

And this is all host i can have when i import the csv
34875667-161a-45c5-9635-80187c700065-image.png

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

@CheekiBreekiHelsinki you have some missing information needed in your first post.

What device is your dhcp server? (manufacturer and version) Is it on the same subnet as the FOG server? You mentioned the VM and FOG server was on the same subnet. What hypervisor are you using? I assume when you say “run PXE” you are saying you are trying to pxe boot the VM? Is the VM in bios or uefi mode? What specifically do you have defined for dhcp option 66 and 67?

Lets start with those questions to see what’s next

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

@NoIPName

I found a solution for this problem:

Apache2 dont care which SSL certificat you use, so you can use another path for your Custom CA on the website
So logicaly you can keep your intern Fog certificat and dont change it :

/var/www/html/fog/management/other/ca.cert.pem /var/www/html/fog/management/other/ssl/srvpublic.crt /opt/fog/snapins/ssl/.srvprivate.key

But you need to recompile the iPXE file for the boot PXE

After that you can check with your fog-client can comunicate with Fog server 😄

In case anyone else is experiencing the same issue, I figured this one out.
routeraddress was missing in .fogsettings

cd /opt/fog vim .fogsettings

enter router/default gateway IP between single quotes

routeraddress='192.168.1.1'

reboot server.

@Jim-Graczyk

The wiki on migration covers migrating a single FOG server using the only workable process, so I’ll leave that alone.

I think my issue with the entire “Server Migration” process is that it requires you take FOG down at the onset of the process - before you attempt to install FOG on the new server. This obviously stops all the PC IT maintenance processes FOG provides IT support, but also FOG’s benefits to the end users of the hosts, until the new server/system is back up and working.

I’ve used FOG on a fairly large scale - some instances have 10+ remote sites, each with its own FOG Storage Node. To say that shutting it down before starting migration is inconvenient to the business is an understatement. Storage node migration didn’t require that the storage node had use the same IP as the old storage node - so that helped.

I hope that my initial post to you comes up when other FOG users search “FOG Migration”, so they don’t waste the time I did trying to build a completely new FOG system, including storage nodes, to cut over to, only to find that you can image PCs and create new hosts, but the exiting host would not talk to the new server system - so all the existing host configuration is lost (a large chunk of work). Ironically, there are numerous FOG wikis that address most issues that I ran into - creating new certs, the ever-present Reset Encryption on the FOG Client, etc., but none mentioned that the CA of the old system HAD to be used in place of the new.

I’m glad there was some way forward without having to reconfigure everything manually, but like many things in FOG wikis, everything in them is true, but context and limitations are not defined at the beginning. Even the migration process link didn’t spell out requirements, nor include remote sites and storage nodes. It needs to spell out that harvesting the CA and certs and using the old server’s IP address are as important as the database, snapins, and images - and this is the ONLY way to migrate.

So - a suggestion to the great minds working on FOG:

Create a way to change the FOG Client CA in one step - delete old and replace new - from within the FOG Client. This could be something issued from the old FOG server, for security reasons. CA deletion should also be built into the FOG Client Installation MSI/EXE. I use FOG to build portable Windows images that are company and FOG server independent. The FOG client is installed at the initial boot and replaced in the image as FOG evolves.

If that capability could be added, migration would be possible such that the new system w database, snapins, images, host configs, could be build out with multi-storage nodes and multi-locations, side-by-side with the old FOG system, gated only by DHCP boot settings at each site (IP broadcast space).

Jim Graczyk