My good, i found it !!!

i the default.ipxe i change the value for my FQDN of my DNS and that work’s !!!

i lost 2 days with this issue :V thanks you !

@bwilli78 my dell machine was wrongly identified as 32bit and sent bzimage32. You can: 1) update to dev-branch 1629 I should help. Or 2) send bzimage to 32bit machines. (Because they are wrongly identified).

This could be your issue. I don’t see FOG sending bzimage32 anyway. Just a gut feeling. May be wrong.

@iljared98 I don’t suppose you’d be willing to share more on this config? What specific rights you gave the service account, did you have to do this whole thing https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1 related to this whole thing https://support.microsoft.com/en-us/topic/kb5020276-netjoin-domain-join-hardening-changes-2b65a0f3-1f4c-42ef-ac0f-1caaf421baf8 ?

I’ve previously attempted to create a standard user with such permissions, but I hadn’t tried a service account, that’s a grand idea. I would love to document the creation of a least privilege service account for fog domain operations.

@fabritrento That’s not how this works. Just saying lol. 6.1.22 works fast for your situation, but that doesn’t mean there’s truly something wrong with the kernel for everybody. So when the next stable release comes out, you should remember to switch back to 6.1.22 and we’ll work to keep trying to update the kernels and hope that you’ll test them to see if it works for your situation so you don’t have to revert it to 6.1.22.

This worked for me :

Domain name: subdomain.domain.tld
OU: OU=Computers,DC=SUBDOMAIN,DC=DOMAIN,DC=TLD
AD DEFAULT USER: adminuser
Domain Password: supersecret
Name Change/AD Join Forced reboot?: cheked

Not sure if I was doing anything wrong, I tried too many things, but this now works. Thanks.

I have the impression this issue has something to do with DHCP server in the gateway competing with proxydhcp in the fog server.

I have updated DHCP settings in Unifi to allow / block DHCP traffic (DHCP Guarding). I have included FOG’s dhcppxory address and seems to be working ok now.

@george1421 This is correct. It works fine. Thanks,

@kbats183 I haven’t looked at the quick registration bit of code but I did have a hack that updated the fog.auto.reg (full registration) option to begin imaging right after registration without a reboot. This involved taking the FOG supplied script updating it to your requirements and then adding a bit of code onto the end and then finally dynamically patching that script on every boot of the target system. It sounds like a lot of steps and its complicated but not if you know how fog works.

I should be able to point you in a direction so you can get started.

When FOG Linux (the os that gets transferred to the target computer for imaging) boots it runs the master fog script stored in the /bin directory in FOS Linux. The scripts bits of that /bin directory is here: https://github.com/FOGProject/fos/tree/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin The file you are interested in is called fog.auto.reg. If you can understand bash script programming you can modify this file to fit your requirements. Once you have the script the way you need it then you can dynamically patch when FOS linux boots using this tutorial (understand this tutorial is for patching fog.man.reg but the concenpt is the same only the file name changes.

https://forums.fogproject.org/topic/13500/dynamically-patching-fos-using-a-postinit-script

I have tutorials that are targeting the manual registration but the concepts are similar. (hint: this is where I tweak the script to give me a custom calculated host name kind of like the auto naming but better. )
https://forums.fogproject.org/topic/14278/creating-custom-hostname-default-for-fog-man-reg

So that’s the background, how do I make it image right after rebooting?
For the fog.man.reg file you append a bit of code that makes the script think the system rebooted and collects the latest imaging info.
(For the life of me I can’t find that tutorial I created but here is the script that I collected from a recent issue with the code in the script.

sysuuid=$(dmidecode -s system-uuid) sysuuid=${sysuuid,,}switch mac=$(getMACAddresses) base64mac=$(echo $mac | base64) token=$(curl -Lks --data "mac=$base64mac" "${web}status/hostgetkey.php") curl -Lks -o /tmp/hinfo.txt --data "sysuuid=${sysuuid}&mac=$mac&hosttoken=${token}" "${web}service/hostinfo.php" -A '' curl -Lks -o /tmp/hinfo.txt --data "sysuuid=${sysuuid}&mac=$mac" "${web}service/hostinfo.php" -A '' [[ -f /tmp/hinfo.txt ]] && . /tmp/hinfo.txt . /bin/fog.download

In the case of fog.man.reg this code would be added at the very end of the script.

Looking at the fog.auto.reg script I would say it should go at the very end of that script too.

ref: https://forums.fogproject.org/topic/17601/deploy-image-right-after-registration-without-a-reboot/3
ref: https://forums.fogproject.org/topic/16378/start-imaging-right-after-the-full-host-registration-without-reboot-possible

@Cristian Any chance you are sending the image out to new/different machines than before? We have just received some new machines into our fleet (Lenovo neo 50q Gen 4), and we are seeing something similar…we get 14GB/min on the older machines, but these new machines are at about 2GB/min. I started a thread on that here:

https://forums.fogproject.org/topic/17698/fog-very-slow-to-deploy-image-lenovo-neo-50q-gen-4/2

Not sure if yours is for the same or similar reasons, but if it is, it might help to know if they are the same machines as we just got.

Thanks!

@fabritrento I’ll be honest, I have no idea what you’re saying is isn’t happening here?

@Tom-Elliott

Yep, that certainly worked. We were avoiding that just so we did not lose all of the location associations that the hosts already had, but if this solves the issue, we will plow through it.

Thanks for the info! This took care of the issue.

@Bhav In addition to what Tom posted, the server response timeout is suspicious too. IF the target computer is in uefi mode and it downloaded undionly.kpxe the target computer should have responded with something about undionly.kpxe is not the right format. But in this case its getting a server response timeout. This makes me think two things. 1) your dhcp opition 66 is set incorrectly or the name of the file has a capitalization issue. For linux Undionly.kpxe and undionly.kpxe are not the same thing. Either way I would start with your dhcp server and make sure dhcp options 66 and 67 are set correctly for a uefi based computer.

@JJ-Fullmer I would mark this one as solved. I didn’t see a way for me to do it. Thanks, again

@Tom-Elliott Even that’s too much for them. They don’t want that NFS is sharing with nobody but without it, it’s impossible to run it I guess unless perhaps using the Samba protocol. Tried to install the latest version of Fog today but got stuk during install.

@fabritrento yes, you can interchange them though sometimes (not the case here) the biggest concern is schema updates between different versions.

In this case, dev-branch is the basis of stable, so these should be effectively interchangable.

@Tom-Elliott All good with 1.5.10.1629

Thanks

@Tom-Elliott latest pull working correctly again. Thanks for sorting!