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? 
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-
@sebastian-roth On my 1.5.9 server you can absolutely see the AD password. It is blanked on the setting itself, but if you go into a host and click the “join domain” you can see that password in plain text no issue. Is this a bug on my system perhaps?
@george1421 Thank you for the information George. The fields that I see it affects where you can actually view the password in plane text are as follows:
storage node general > Management Password
Hosts >pick a host > Active Directory > Domain Password
Fog Configuration > Fog Settings > Fog Storage Nodes > STORAGENODE MYSQLPASS
Fog Configuration > Fog Settings > Proxy Settings > Proxy Password
Fog Configuration > Fog Settings >TFTP Server > TFTP FTP Password
Could be others that I am missing, but these are where users of the GUI on my server can see the password in plain text. The ability to toggle this feature on or off would be great. Probably requiring an admin password to change the toggle. Thank you very much!
We have FOG 1.5.9 installed, and for security purposes we were curious if it was possible to remove the plain text viewing of passwords in the various locations this shows up? Our security requirements are fairly strict, and this would be helpful to not have the password show in plain text to those who have access to the GUI. Happens in several locations we notice, including with domain accounts for joining machines to our domain post imaging. Any thoughts or assistance is appreciated. If this is not possible, would it be possible for me to submit a feature request for this? Thank you all!
-Josh-
We found that we had to fiddle with a good many settings in the bios including UEFI boot path security and a few others. Even then the only way we can get to it is by doing “F12” and manually choosing PXE Boot which is very strange. It works after that however. This can be closed out.
We have 15 or so Dell Latitude 5420 laptops, we have configured them for UEFI, PXE boot, AHCI, and disabled secure boot all per our normal routine.
When it starts to boot, it finds no compatible pxe boot and skips it and continues in the boot order. We are on version 1.5.9.62 of FOG, with a version 5.10.50 Kernel. It feels like the Kernel doesn’t support this particular device, but could it be something else we are missing? Anyone have any suggestions or experience with Dell Laptops this new?
@george1421 I will certainly never try to upgrade CentOS forklift style again. You were correct I upgraded Centos from version 7 to 8. After the mess it created I took your advice and ran the FOG installer using “GIT” and it cleaned up a bunch of the issues. A BOAT LOAD of things were missing after the upgrade but now they are functional. Thank you for all the assistance, FOG’s community and dev team is top notch.
After updating Centos to version 8, my fog server no longer PXE Boots for UEFI clients (that is all we have). We get the attached error, it claims the error is “PXE-E99” and that the “NBP filesize is 0” and then PXE skips right on by. I believe it is something to do with the upgrade of Centos but not sure what exactly. The interface names did change from em1 to eno1 Anyone have any suggestions? Currently unable to image at all.
@rogalskij And I answered by own question after reading this post. Very helpful and explains the difference in the kernel versions. Very helpful as always!
https://forums.fogproject.org/topic/14732/kernel-versions-4-19-143-vs-5-6-18
@george1421 I upgraded to the 5.6.18 and it fixed it! What I don’t understand is why the 5.6.18 kernel is lower in the list of kernels if it is the “latest and greatest” kernel. Shouldn’t it be on top instead of the 4.19.145? I am a bit confused by this.
Also, forgive my ignorance, but what does LTS stand for?