Cool - issue resolved!

This was absolutely an issue on our network, but we’re not sure if it was an old static Rendezvous Point that was configured on our core or if it was our VPC redundancy between our two nexus switches, but we were able to solve it by disabling pim on one of the nexuses and removing that static RP.

Thanks for the help on investigating, everyone. It’s much appreciated.

@Wayne-Workman Good catch - I need to read the manual!

I’ll go through and update everywhere as it states, then try again. Thank you!

@Tom-Elliott Thank you! This helps a lot! Funny enough, it was tftp-server that I installed. I suspect we may have had a different issue (maybe during a patch management cycle) and these things just got tied together.

Hello team,
We recently updated our FOG server from 1.5.10.1593 to 1.5.10.1615 and our PXE booting stopped working afterward. We tested on both UEFI and Legacy boot and found that TFTP was timing out afterward.
I’m having a hard time identifying which service FOG is using to run its TFTP – the documentation talks about Fedora and Ubuntu, but I’m using RedHat 8.10, and neither of the services listed for Fedora or Ubuntu were present.
As a work around, I just did a good old-fashioned “yum install tftp” and changed the config file to point to /tftpboot. This worked to restore service, but I noticed that the PXE boot menu doesn’t look the same afterward. I suspect it’s because I’m not using the same service / config file that FOG usually does.

Is there another service I should be checking to ensure FOG is working correctly with TFTP? That way I can shut off my other “workaround” TFTP service that I setup?

Yup that did it! I was in the middle of copying files up to the server when you replied. Put them in that directory and rebooted and the errors went away. We’re good to go.

Thanks for the help @george1421 . Feel free to mark this one as solved.

@george1421 Thanks for the heads-up. I’m not using any USB flash sticks – I’m using a PXE boot setup. So would these need to go in /tftpboot on the server instead? Or another location?

I don’t know if this is helpful or not, but I found some e1000 references in the /var/log/messages file. Did not see a syslog file anywhere.

Thanks @george1421 ! I ran those commands, and I think the /var/syslog might be for RHEL where I’m on Ubuntu 16.04 LTS.

But your point on the kernel version is interesting, as I’m only on version 4.11. I thought I had updated to 4.19 yesterday in the Kernel Update thread.

So to test this a bit further, I ran the FOG kernel update again and rebooted this machine into Debug mode. The kernel update that the FOG management page says I’m installing is 4.19. The update succeeded without error. Rebooted the client into its debug task, and ran uname -a again, and still only see version 4.11.

So I realized if I simply press Enter a few times at that error, I still get the debug prompt. So I tested the commands, as recommended:
ip addr show
lspci -nn|grep -i net

Below are the results of these commands!

Thanks @george1421 . I manually registered the client via Mac Address in FOG and pushed the Debug task to it. When booting into the task, I get the same error message. See the screenshot below. This is what makes me think I need an updated kernel.

EDIT: I’m a dumb-dumb. If I press Enter a few times, I get to the debug prompt as expected.

Hello everyone,

As a follow-up from my previous thread, I am having trouble registering a new model of computer in FOG. Other computers register and images upload and deploy just fine, it’s just this new model. I’m working with the Dell Precision 3630 on this.

I can boot to PXE, obtain an IP Address, and get to the basic FOG menu no problem. From here, we typically do a Full Host Registration and Inventory before attempting to deploy any images, so that we have the host registered and trackable. We also use this for automating items like Hostname Changer and Active Directory domain joining.

Once I get to the basic FOG menu, I select the option for Full Host Registration and Inventory, and I am greeted with the error in the screenshot at the bottom of this post.

At first, I believed this to be related to a kernel, so I did update the kernel as noted in my previous post. This did not correct the error at all.

My kernel is now on version 4.19.36 TomElliott (May 1, 2019) and I’m using FOG version 1.4.4, SVN version 6077.

In the previous thread that I’m migrating this issue from, @george1421 suggested that I cancel any tasks I have assigned to the host and push the “Debug” task to it. I have been unable to do this, as I have not even been able to register the host in order to assign any tasks thus far. I’m just trying to get through host registration first.

EDIT: Typos corrected.

Great! Let’s mark this one as solved. In short, the issue for the kernel update was related to the permissions on the /var/www/fog/service/ipxe folder, which was a confirmed bug in version 1.4.4.

I’ll move the other issue to a new thread. Cheers!