Posts made by rogalskij

Simply Installing “Postfix” on Alma Linux and rebooting the server did the trick. After the server came back up, I successfully deployed an image, and afterwards the email came through without an issue. Had all the information filled out appropriately as well. Thank you very much Tom!

Requesting a feature addition in the “FOG Settings > FOG Email Settings” section that would allow an admin to test whether or not email is working. This would be similar to other programs that have a “test email” button with a box of who to send the test email to.

Or perhaps some built in logic to test if postfix or other email prereqs that FOG needs to send email post image deployment.

@Tom-Elliott As usual Tom you are a genius. I had forgotten to add the individual search domains for our active directory domains. Once I added those, and waited the requisite amount of time you mentioned, the machines that are on came back and now I can see them in the interface. This was super helpufl and I sincerely appreciate all the effort and insight you folks give into this great product.

For those experiencing the same issue on mainstream linux distros, navigate to your “resolv.conf” config file located in /etc/resolv.conf and add your individual search domains. Test a ping to a DNS name via command line on the box itself, then check your GUI again. Took about 2 minutes for it to reflect and show for me.

@Tom-Elliott

I thought FOG used “sendmail” so I installed that on the box. I am working on FOG version 1.6, and i copied over the settings from my previous working FOG install, but I suspect the email software on linux itself not being configured is where the issue is.

We do have an internal SMTP server that I could relay to, if that is a possibility. I would just need to know where in linux to configure that relay. I guess what I need is where to start looking for email config using sendmail, or some other built in linux mail program.

Version 1.5.10.1629
Environment - Dell Poweredge server running Alma Linux 9.5
FOG client 0.13

We recently migrated to a new FOG server (Wanted newer/better hardware). While FOG installed, and is functioning when capturing and deploying images, the “OS Details” feature on the “Hosts” screen shows a red exclamation mark for all new hosts we attach. Previously on the old server, it would sometimes glitch and show the exclamation mark. Now ALL of them show this. Am I missing a setting in the FOG client or Windows firewall setting on the host PC? While the feature isn’t critical, it was nice to see all green across the board. Thanks everyone!

Version 1.5.10.1629
Environment - Dell Poweredge server running Alma Linux 9.5

We recently migrated to a new FOG server (Wanted newer/better hardware). While FOG installed, and is functioning, the email function that occurs post successful image deploy no longer works.

I installed sendmail on the linux server, and set the settings in FOG Configuration > FOG Settings > FOG Email Settings to match the settings on our old server. Is there something I am missing? Did I have to modify a config somewhere or something? Or add in settings to sendmail to get this to work? Any assistance would be appreciated as this was a nice feature we enjoyed.

Version 1.5.10.1629
Environment - Dell Poweredge server running Alma Linux 9.5

Not to dredge up an old forum post, but I experienced this same error after migrating from an old CentOS server to newer hardware and Alma Linux. (What apparently many are moving to now).

For me the issue seemed to be related to trying to pull an image from a laptop that had the previous client on it. I have 2 computers that I use as dedicated imaging devices, 1 laptop and 1 desktop. I uninstalled the old FOG client, but when installing the new client and attempting to point it to the server, I got the CA Certificate error mentioned on the “Pinning” stage of the install. I tried to find an old cert on the device itself, with no luck.

What I ended up attempting after doing a little digging was to add back the following Windows firewall rules. I did that, and it seemed to kick over immediately and installed on the very next try. I am unsure if this is coincidence or if the firewall rules truly needed to be on the device before installing. But it worked after that and I now have a successfully pulled base image like I utilized on the previous server. The rules I used in an elevated command prompt are below. Perhaps someone from the FOG community can comment on the accuracy of my firewall rules? Good luck and hope this helps someone in need!

netsh advfirewall firewall add rule name=“Fog Client” dir=in action=allow program=“%ProgramFiles(x86)%\FOG\FOGService.exe”
netsh advfirewall firewall add rule name=“Fog Shutdown” dir=in action=allow program=“%ProgramFiles(x86)%\FOG\FOGShutdownGUI.exe”
netsh advfirewall firewall add rule name=“Fog Tray” dir=in action=allow program=“%ProgramFiles(x86)%\FOG\FOGTray.exe”
netsh advfirewall firewall add rule name=“Fog Update Helper” dir=in action=allow program=“%ProgramFiles(x86)%\FOG\FOGUpdateHelper.exe”
netsh advfirewall firewall add rule name=“Fog Update Waiter” dir=in action=allow program=“%ProgramFiles(x86)%\FOG\FOGUpdateWaiter.exe”
netsh advfirewall firewall add rule name=“Fog User Service” dir=in action=allow program=“%ProgramFiles(x86)%\FOG\FOGUserService.exe”

UPDATE

After some investigation, I found that if I connect to FOG using the FQDN, the Kernel versions show. If I connect via IP address, which I had been previously, it doesn’t show. This was on a machine with our Endpoint protection enabled. On a machine without any endpoint protection, both IP and FQDN show the Kernel versions. Strange, must be some sort of overzealous web protection on the part of our endpoint software. Thanks for your help @Tom-Elliott !!!

@Tom-Elliott Correct, in yours you see the bzImage and arm_image, but in mine it is totally blank for some reason. Been like this for quite a while and I have no clue what I did to cause it. Unless it is potentially just a browser issue or something with my PC only?

Current version - 1.5.10.1598

Several versions ago, I found t hat under the “Kernel Update” tab, it no longer shows me which Kernel versions I have installed. If I clicked on “Default Member FOG Version: ()” it would list what versions of the kernel were installed. It stopped working some time ago, and I didn’t mess with it. Is there an easy fix for this? I have tried updating and a few small changes but no luck. Not a huge deal, but would like it back if I can. Thanks everyone!

Finally finished a brand new image this morning where we started from a fresh Windows install. The image captured without an issue. I suspect the age of our previous image was to blame for the issues with the capture. I think recent Windows updates by Microsoft to the recovery partition may have modified the size or something else in those recovery partitions.

New image pulled using the 6.6.34 Kernel, and then deployed successfully as well. If anyone is having issues related to the errors I posted above, I would try the CHKDSK + defrag/trim, and if that doesn’t work I recommend rebuilding your image from a clean Windows install with the absolute latest Windows enterprise installer.

Thank you Tom and crew for all the excellent technical assistance!

@Tom-Elliott Was going to try, but discovered that after the last CHKDSK, the FOG Client wasn’t running correctly. Now I can’t uninstall or reinstall it correctly. I think for now I am going to re-create this image from scratch. I am speculating that since this was an older image that we had added onto several times, that a Windows update of some kind caused partition issues of some sort. I plan to format and install Windows from Scratch, and then build the image and pull it tomorrow. If this works I will report back with my findings.

In the meantime, are there any logs that I could send that would help you or anyone else who also finds themselves having this issue? Happy to assist in any way I can. I sincerely appreciate all the support and assistance on this.

@Tom-Elliott I believe you are correct. I ran a CHKDSK /F and it repaired the disk, but now I am faced with a new error. It claims “could not allocate new MFT record: No space left on device” and several other issues. Not sure where to go from here other than perhaps start a new Fresh Windows image?

@Tom-Elliott

Thank you, while looking at the log, I noticed an oddity and after reinstalling the FOG client, it is now fixed. I appreciate the assistance in helping me track down this problem. The tasks are working correctly when coming from the FOG server itself now. I appreciate it!

@Tom-Elliott So, does that mean I need to add port 80 and 443 to an inbound TCP rule on the machine I am trying to capture from? The client seems to not pick up the task no matter how long I wait. I assume it shouldn’t take more than 60 seconds or so.

Thank you for helping with this.

@Tom-Elliott said in Cannot capture image: run lists overlap:

nfs-kernel-server

I am getting this error in 1.5.10.41 after updating. I am running on CentOS 8. I restarted my NFS Server, but that didn’t seem to do anything. I noticed that the NFS “interfaces” were pointing to something other than my servers interfaces so i changed those to match what the server says is the network interface. Not sure if NFS interfaces are something different or they should match as well? Any assistance on how to troubleshoot this would be great as I have an image to capture and at this time can’t accomplish that.

We are a FOG Server school, and we utilize the .13 client. We are on version 1.5.10.41 which we recently updated to. When we attempt to start tasks, the client on the machines don’t seem to execute the tasks regularly. I am thinking it is because we are missing firewall rules on the machine we pull the image from, but am unsure. Are there specific ports we should be adding on the client itself in Windows Firewall? If so, what are they, and are they inbound, outbound, TCP or UDP?

Any assistance would be appreciated. We have the FOG client itself in the Windows Firewall inbound list, but doesn’t seem to have changed anything.

@george1421 Thank you for checking in. So strangely I was able to get it to start up by replacing the permissions on: /tftpboot and “/var/www/html/fog/service/ipxe". I am not sure if this made the difference or was a coincidence or?

Imaging is now back to working as it did before. One thing I was curious about, what program is used for TFTP on CentOS 8? I couldn’t tell which product FOG uses, is it vsftpd?

Starting Friday the 5th (or late Thursday the 4th) our FOG server stopped PXE booting the clients. We have tried a reboot as well as checking several other small things but we have had no luck.

When the client boots, it starts UEFI pxe boot but fails so quickly we can barely see the message. The error itself (attached below) when slowed down claims “PXE-E23: Client received TFTP error from Server”

This seemed to coincide with OS updates for CentOS 8 but I am not 100% sure that was the cause. Not sure what could have broken with TFTP but any suggestions would be appreciated. August is our busy season and we are lost without FOG.

@george1421 and @Sebastian-Roth I really appreciate everyone taking a look into this so it could possibly be fixed in a later release. We use FOG every day at our College so I tend to come across different quirks time to time. So appreciative of the product and the support provided by the community, devs, and users. Thanks and take care!

-Josh-