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

@ITCC Someone much more cleverer than me (from ANME) has worked out how to fix it and it is due to sysprep sealed images rather than Fog persay as Tom suggested. the Fix is to add the following to your sysprep SetupComplete.cmd file

for /f "tokens=2 delims={}" %%a in ('bcdedit /enum {bootmgr} /v ^| find "identifier"') do set prep-bcdid={%%a} bcdedit -set {current} device partition=c: bcdedit -set {current} osdevice partition=c: bcdedit -set {memdiag} device partition=\Device\HarddiskVolume1 bcdedit -set %prep-bcdid% device partition=c:

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

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

/etc/pam.d/vsftpd looks fine

#%PAM-1.0 session optional pam_keyinit.so force revoke auth required pam_listfile.so item=user sense=deny file=/etc/vsftpd/ftpusers onerr=succeed auth required pam_shells.so auth include password-auth account include password-auth session required pam_loginuid.so session include password-auth

ftpusers file:

# Users that are not allowed to login via ftp root bin daemon adm lp sync shutdown halt mail news uucp operator games nobody

@cros I’m kind of spit balling here but your imgargs line especially around nfsroot doesn’t really follow what I expect.

FWIW here is what I have in my guide for debian 11. (I really don’t keep up with current distros anymore)

kernel tftp://${fog-ip}/os/debian/Server11.3/linux initrd tftp://${fog-ip}/os/debian/Server11.3/initrd.gz imgargs linux initrd=initrd.gz root=/dev/nfs boot=casper netboot=nfs nfsroot=${fog-ip}:/images/os/debian/Server11.3/ locale=en_US.UTF-8 keyboard-configuration/layoutcode=us quiet splash ip=dhcp rw boot || goto MENU

For me your imgargs line stands out as is your 192.168.7.5 server your fog server or a different server? If its your fog server you can make the line a bit more portable by using ${fog-ip} which will be replaced by the IP address of the fog server by iPXE. Secondly did you create an /nfs share on your fog server because that is not one of FOGs standard nfs shares. On the fog server you should be able to run the command showmount -e 127.0.0.1 to see the list of nfs shares on the fog server. In my imgarg command you can see I’m using /images/os which is in the path of /images on the fog server and /images is an NFS share.

ref: https://forums.fogproject.org/post/150256

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

Hello, some one can help me ? 😞

@AUTH-IT-Center That is correct. That’s what that FOG Settings item is meant to do. If that is checked, on registration it should set that flag on future registrations, but it doesn’t on existing hosts that were registered before it was checked. If after this is checked and a new host registers and this isn’t working, I would believe there to be a bug.

Though a workaround exists, so while, it would be a bug, it may not be the biggest concern to get fixed immediately over say actual imaging issues.

@george1421 I appreciate your response. I went ahead and tried to install ubuntu 24 via a USB drive and got the same issue. I’m going to reach out to the manufacturer.

@Tom-Elliott

Hi Tom,

We have added a column to the ‘location’ table in the fog database and we have given this column an ENUM ‘http’, ‘https’. The error message disappeared.
Should anyone run into the same problem, you can at least remove the error message from your logs.

We still have image-task problems but we’ll deal with those now.

Thanks.

Regards, sassonie

@PatrickL You might want to review this post: https://forums.fogproject.org/topic/17648/massive-cpu-usage-from-a-service

That .sysvd is suspicious and very similar to the thread above.

I believe I have a viable migration process to get FOG services moved from set of servers to another set. This process takes into account Locations, Storage Groups, existing Hosts, etc. The system I’m migrating has 7 remote sites so that’s 8 locations and 8 servers - one FOG server and 7 FOG Storage Nodes, each at the end of a Static VPN WAN. The initial FOG server is an alias ‘fogserver’ in DNS and DHCP is served out by MS Domain Controllers at each site. Each Storage node serves out all that is needed for each remote location (PXE, initrd, snapins, and images). Each storage node is the master of its own storage group. We do replication manually, so there may be some snapin and image replication issues in this process that I can’t account for.

The process requires being able to harvest the digital identity of the initial FOG server for use on the replacement FOG server, so the replacement server needs the same name and IP address. This is necessary to allow existing hosts to be easily ‘acquired’ by the new system since the Hosts. I pursued a side-by-side migration that worked fine PXE booting->host registration->imaging, but failed for existing Hosts and, for unknown reasons, even new Hosts failed all software distribution steps. The idea of placing FOG required scripts in group policies wasn’t appealing for my purposes since we need the FOGService to work without the machine joining a domain.

I’m currently testing and will have a process “doc” soon. I’m interested in posting this process for FOG Project’s use if the powers that be find it useful.

I’ll post it here when it’s completed.

It seems to me that the need to change Linux distros is an age-old requirement as various Linux OSs have been dropped or usurped. Migration of FOG from CEntOS to any other Debian Linux should be well documented.

More soon.

Jim Graczyk

@Eliseu
this ip 192.168.0.17 is from the virtual machine that is trying to boot into the pxe, the ip 192.168.0.16 is the fog server