Network Technician at Cayuga Community College
Found the issue! After some research and discussion with Cisco, we had to add “PIM” to the vlan on our core, even though both the server and client are both on the same vlan!
Used the command - ip pim sparse-dense-mode on vlan 1 interface and it started working like a charm! I really appreciate everyone’s assistance here. This will help our institution so very much.
As always, the community comes through! Not sure how this got askew, but following these directions I was able to fix the issues. The image pulled correctly and at the end updated the database info. The image is good, I am all set. Thank you again this was awesome!
@Tom-Elliott Good thinking, I just attempted that but it seemed to make no difference. My clients still seem to hang on the partclone screen. I did reach out to Cisco to check to see if my 6509E core switch has all the correct settings on it for multicasting. I also made sure the port the server was on is using “port-fast”. It worked like a charm the moment I plugged it into the edge switch. I will do some more testing while I wait for Cisco to answer me back. Sorry for all the back and forth with this, I really do appreciate this product, it’s developers, and the dedicated community behind it.
@george1421 I watched during the deploy but didn’t see anything relating to which bzimage version it is using. Odd. I have a feeling it is still using the other bzimage. I am going to test by backing up the current 4.19.101 bzimage and renaming the bzimage533 to “bzimage”. Just a temporary test.
@Sebastian-Roth Testing with newer init with partclone 0.3.13 and kernel 4.19.101 seems to fix my slowness in deployment of images. I am seeing speeds of 9GB or more in my testing now. I am guessing it is the partclone that is causing the slowness in some environments. Will continue to test and utilize 0.3.13 partclone to verify theory.
@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.
@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?