@steveo Sorry I thought about a few more questions on the commute into the office.
Stick with me, because they are specific leading questions…
I do want to think about this for a bit. But lets collect a bit more information.
There are more questions, but lets start with those.
@loosus456 They (M$) did something with disk structure, as well as other numerous changes under the hood. Some changes caused several rounds of rework to the fog client. I don’t have specifics, but based on some of the threads we’ve seen the issues started with 1709. I’d have to go back through the change log to pin point the fixes specifically related to 1709.
I think one from my testing was I had to move starting of the fog client from the setupcomplete.cmd to a first login step in the unattend.xml because the windows was doing some additional things after the setupcomplete.cmd. If the fog client was started too early (in the setupcomplete.cmd) I would end up with a botched install. This is different than all of the win10 releases before.
@hammett131 If you can’t get your sonicwall to cooperate you can install dnsmasq on the FOG server to dynamically supply the boot information while you still use the sonicwall for dhcp services. There are a number of ways to get things working in your environment.
@hammett131 ok I see why it doesn’t boot.
The device is saying its a uefi system (EF-BC type 7) but 10.0.2.1 is sending undionly.kpxe as the boot file name. The target computer promptly downloads the file and chokes on it. Its saying the next server is 10.0.2.122, which is your fog server?
@hammett131 If you use this filter
tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011
it should create output.pcap in the current directory where you ran the tcpdump command.
@hammett131 It should dump the output into a file you cited in the tcpdump command. 6 packets is about right for dhcp boot.
@fallingwax If you can get the target computers and the fog server on the same subnet we can capture a pcap of the pxe booting process using this procedure: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
Ideally I would like to capture the pcap from the FOG server perspective so we get both broadcast and unicast communications. Also ideally we would like to capture a failed pxe boot on the dells as well as your Posiflex systems.
While I didn’t compare the dnsmasq files between the link you provided and my post about dnsmasq 2.76, please use this config file.
Assuming you have dnsmasq 2.76 or newer installed this config file works. To find out what version of dnsmasq you have, key in dnsmasq -v
# Don't function as a DNS server:
port=0
# Log lots of extra information about DHCP transactions.
log-dhcp
# Set the root directory for files available via FTP.
tftp-root=/tftpboot
# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,<fog_server_IP>
# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override
# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009
# Set the boot file name based on the matching tag from the vendor class (above)
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,<fog_server_IP>
dhcp-boot=net:UEFI,ipxe.efi,,<fog_server_IP>
dhcp-boot=net:UEFI64,ipxe.efi,,<fog_server_IP>
# PXE menu. The first part is the text displayed to the user. The second is the timeout, in seconds.
pxe-prompt="Booting FOG Client", 1
# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
pxe-service=X86PC, "Boot to FOG", undionly.kpxe
pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe.efi
pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe.efi
dhcp-range=<fog_server_ip>,proxy
Be sure to update <fog_server_ip> to match your fog server IP address.
@ldiorio Very interesting. Have you run a diff between the two config files to see what was changed? Its good you found this issue before FOG 1.5.0 (stable) is released.
@hammett131 That is odd. I can tell you a uefi system will not boot a bios based kernel, and the same way around. They are two different ach types. I think generating a pcap of the process is going to tell us really what is going down the wire. You may have an unexpected dhcp server helping you out.
@foglalt Understand this is all subject to change, but I think the plan was RC13 to be the last before 1.5.0 stable was pushed out in a couple of weeks. Internal changes in Windows 10 1709 has caused unexpected delays with 1.5.0 being finalized. GUI performance improvements were pulled from 1.5.0 and moved into the 1.6.0 branch which should be released in the first half of 2018 (maybe).
Fog 2.0 IS a bit out there yet. The devs have said that they are seeing some pretty impressive deployment speeds with the pre-alpha code.
@hammett131 Well and I’m old and I forgot to paste the link in. I had the link in the copy buffer, but just failed to execute. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
Since you are not using a standard dhcp server, make sure there isn’t a spot for bios and a different one for uefi mode devices. I know pfsense has unique spots for each boot file name.
Check to see if you have an extra white space on either side of ipxe.efi. If all else fails follow these instructions and post the pcap to a google drive. Either post the link here or IM me directly and I’ll take a look at it to see where the pxe booting is going sideways.
@irfan4701 Interesting because xfs is the default since centos 7 was released. But this is great news, now we have something new to go back to the devs with.
@mpsadmin My intent was to set this back up in my lab but day to day work has got in the way.
From looking at the code it appears that the fog server replication connects to the storage node over FTP and pulls the target file size. If they are not the same then the replicator starts over.
@ldiorio Really, older is better? I’m glad you have it working, but a bit surprised with the results. I’ll take this info back to the devs to see if this is just a one off issue or there is an issue with the updated version of refind, since refind is an external package included with FOG.
@bobbyfrank ok I’m seeing a pattern here.
The FOS engine uses tftp, (dhcp if using FOG as dhcp server), (proxydhcp if you have dnsmasq installed), http/https and NFS protocol (this is the point where its currently failing, making the NFS mount to the fog server).
Do you have some kind of screening router/firewall between the target computer and FOG server?
@bobbyfrank OK the null message is a good thing, I think. The Null means that (translation provided) “You did not schedule anything for the FOS engine to do on the FOG server before you booted via USB” Please schedule a task on the fog server first then usb boot into FOS.
I really need to get that NULL message fixed so its a bit more meaningful. The FOS USB was only intended to be used for debugging, but now its being used a bit more.
@ldiorio As a test, can you grab refind from here: https://sourceforge.net/projects/refind/files/0.11.2/ (grab the zip file) and extract refind.exe and move that into the fog/service/ipxe directory (renaming the original one). The version of refind on FOG 1.4.4 is older. I want to see if the newer version manages the exit better.