@Tom-Elliott
Thank you for your attention.
I did not find a solution. In my business, we have chosen a different type of computer and everything is fine.
It’s just so that you can close or delete this topic which is useless in the end.
I need help elsewhere, but I have a new topic on this subject.
Thank you for this Fog product which is powerful, varied and effective !!!

@msi I am wondering why you have two IP addresses within the same subnet assigned to your FOG server? Any good reason to do this?

I also noticed that it is using enp0s31f6 IP address instead of p2p3 IP (192.168.1.230). is it normal since both IP’s are working when accessing the web console?

FOS uses the IP set as FOG_WEB_HOST (FOG Configuration) to call out to the FOG webserver. I suppose you have set 192.168.1.230 in that field, right? That shouldn’t matter from my point of view.

If you have checked all the passwords and resynced as described by George I may ask you to do a simple FTP test: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

@beardedfool If you want to go secure boot there might be a way using your own custom Certificate Authority to roll out things. I haven’t done this myself and can’t give you any details. You’d need to talk to @Lee-Rowlett about this. First checkout his posts here: https://forums.fogproject.org/topic/13832/secureboot-issues

@Sharo It’s not that hard to get this back up. No need to reinstall just because of that. Shall we do a shared desktop session? See speak bubble in the top right corner.

@Sebastian-Roth Thx for your help, Sebatian!
I commented out line

chroot_local_user=YES

And now everything is just fine about my FOG installation.
MB it makes sense to add into FOG wiki - that vsftpd option is incompatible to FOG.

Now I need to find a way to chroot one user but not to chroot other, but it is definitely not a FOG problem. (And, it’s simple)

Thanks again.

Best regards!

@ddo Do you have some GPOs or other means of software deployment in place that would install 0.11.16 after 0.11.17 was installed?? I have done some intense testing on this back in the days when this came up and I am fairly sure it’s not FOG doing this by itself. But it is possible due to missing checks in the MSI installer if you use other means of deployment alongside.

Solution: Uninstall both, re-install one, maybe even use the latest release 0.11.19.

@Sebastian-Roth said in Active Directory (Groups) settings lose settings when a new PC joins the group through host registration:

persistent groups

Thank you very much, I enabled plugins in my Fog Settings and installed it there, I appreciate that!

Thanx! Will try!

@jserowoky Is SELinux enabled or disabled? Run getenforce and post output here.

Change access rights on the folders (chmod 775 /images /images/dev) and try capturing again.

In /images/dev the temp folder appears using a random alphanumeric name, which I’m assuming is normal.

Yes, we use the MAC address (without colon or hyphen notation) as temporary folder name in /images/dev.

@marianheinsen Sorry to say this but it’s a known issue which would need major work to be done on the fog-client software which we don’t have the resources to do at the moment.

https://github.com/FOGProject/fog-client/issues/116

I restarted my fog server and made sure that the fog server node also had a copy of the snapins on the server. After that, I added the snapin and gave it about an hour before I moved on to checking the snapin list.

Thanks for all the help but i finally decided to reinstall everything from scratch.

Thank you Sebastian for this explanation.
I actually use the short name but by default, I would have preferred to use the long name.
But the whole is currently configured as well, so I will stay on this configuration while waiting to update the posts with a new image at the end of the school year.

@Fog_Newb said:

Either use groups as suggested by George or add it to the global settings: FOG Configuration -> FOG Settings -> General Settings -> KERNEL ARGS (not sure if this would cause trouble for other hosts as we don’t know all the other hardware you have)

This ended up being the case. Apparently there was a bug in the version of ipxe.efi and cloning the version in the github repo below resolved the issue. I was so caught up in other things I forgot to actually try this until I was reading over this thread again today.

Thank you for your help!

@george1421 said in UEFI Boot:

@londonfog Hmm, ok that isn’t it then. I thought it was possible that something happened with the 1.5.8 update and ipxe.efi was damaged some how.

In each of the boot loaders (undionly.kpxe and ipxe.efi) there is a script that calls default.ipxe on the FOG server… But thinking about it now, its getting past that point because it calls default.ipxe which chains to bootp.php. That http call is failing for some reason. So default.ipxe has already been loaded by ipxe.efi.

I don’t have an answer why only uefi has this issue. I can say that 1.5.5 is kind of old, but I don’t remember your issue being an issue in 1.5.5. I guess you could try ipxe.efi from 1.5.8 to see if that changes anything. Here is the link to the github site where you can download ipxe.efi https://github.com/FOGProject/fogproject/tree/master/packages/tftp

There is 2 ways to image target computers. The first method you already know, but registering the target computer, then select image at the end of the process or schedule a deployment in the web ui. You uses this method if you want FOG to manage the target computer after imaging. In this method the FOG Client is used to name and connect the computer to AD.

There is another method that MSP (system rebuilders) use need to load an OS on the computer, but the computer will not be managed by FOG after imaging. Typically once a system rebuilder loads a computer that computer is put up for sale and is never seen again by the FOG server. You access this method via the Deploy Image iPXE menu.

There is another process that is in between these two methods. Where you use the Deploy Image menu to image the machine, but the system name is caculated in a post install script and the unattend.xml file in windows is used to connect the computer to AD. In this case the fog client isn’t used or needed. If the FOG Client is installed in the image it will contact the FOG server after OSD is done in windows and will be added in a pending state in the web ui. From there you will need to accept the system in the UI and then you can manage the system.

So there are a couple of ways to image a machine, none are totally hands off and some take some setup to complete.

@Sebastian-Roth Understood. Sorry. I will make a new thread.

OK, I’ll try it soon
Thank you @Sebastian-Roth

This has been solved, the problem was our Cisco switch, somehow it was blocking the download

just to let you know that the issue was solve this week buy updating the latest version of fog
seem that you finaly found the problem

thank’s