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.
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?
Tried to deploy our existing image to Dell Latitude 5410 laptops. Deploying these to the laptops manually via the “keyboard method” (not registering in the console but just going through the menus right at the laptop).
Makes it through the menu system of the server, I choose the image and then when it starts deployment, it throws an error “No network interfaces found, your kernel is most probably missing the correct driver!”
This is odd since it netbooted and I am on the latest version of FOG 1.5.9, not sure if it is a kernel issue or something else. I updated the bios and tried several of the laptops. My Kernel version is 4.19.143 which claims it is the latest in the list. Any suggestions?
The process is as follows for a new machine never having been imaged. Desktop support tech sets all the necessary BIOS settings to get it to PXE boot. Then said technician PXE boots the machine, images it without registering it, and waits for it to reboot. After it reboots, the technician logs in locally and renames it while at the same time joining it to our Active Directory Domain.
Then I log into the console sometime later and I notice that yet another mac address has been crammed into a machine in the console.
Sorry I didn’t respond until now. We are still having the issue. For these machines, the majority we DON’T register beforehand. These are usually imaged by our desktop team at the PC using a manual “netboot” on the machine itself and then imaging it. Then we end up with hosts in the “Pending Hosts” section or in this case they never show up there because they show up under some other previously imaged machine as shown in the image I posted. We rename the PC manually after it get’s imaged in this case.
Currently we have the default setting of “Change hostname early” set, should we disable this?
I do have the FOG client installed in my image as I thought this was the desired behavior to “capture” an image
If we need to rename the PC BEFORE imaging, how would we go about this but still utilize the manual imaging process right at the PC itself? (My desktop team prefers to image this way even when the original image on the machine is functioning correctly).
I will certainly turn this off in my image, but the mac address that shows up on another machine, is a real mac address of a machine that I just imaged. So let’s say I image a computer named “PC1” using the manual keyboard based method of FOG. Then after I go log into the console, I can’t find it under “pending” or anywhere else. That is because it’s real primary mac address is listed under “PC7” or some other host on the FOG console under “pending macs”.