Posts made by kenneth.sisco

@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!

@george1421

Tested the client and it doesn’t look like the kernel update fixed the problem. I installed PC 32-bit and PC 64-bit kernels (both version 4.19.36, last updated May 1, 2019).

So getting to the crux of the issue I was trying to solve, I am getting the error on the client noted in the screenshot at the end of this post.

Now I know that the network and PXE booting are fine, as I can actually PXE boot to the FOG menu without a problem and it gets an IP Address through that on the subnet that I expect. Once I get to the FOG menu, I select “Full Host Registration and Inventory.” I am then welcomed with the below error message. I believed this to be related to the kernel, which was why I was doing the kernel update in the first place. Was I wrong?

Also, if you need me to create a separate thread for this issue, let me know. I’ll mark this as solved and start a new one no problem.

@george1421 Ah thank you – it looks like I got to the same point on that one. I just attempted the command you noted:

sudo chmod -R 777 /var/www/html/fog/service/ipxe

This completed without error, but now I do the command to check:
ls -l /var/www/html/fog/service/ipxe

I get that the directory doesn’t exist. I changed your command to instead be a direct copy/paste from the TFTP Server settings in FOG Settings instead. This location is: /var/www/fog/service/ipxe (note the lack of the /html/ directory in the middle). The commands seemed to work in that case.

Tested the Kernel update again and SUCCESS! Looks like we’re in business.

Side note: I don’t really care about security on this box, as it’s shut down 90% of the time. We only power it on when we need it because we don’t want to worry about hardening it.

Thank you for the help. I’m going to do a test run with a client and see how it goes!

Apologies again for the double-post, but I’ve been researching further on this error and the Wiki points to this being a permissions issue. I have checked the following items:
/tftpboot is set to 777
/images is set to 777

These are the only two directories that I am aware of that are used for the FTP side of things.

I also opted to check the TFTP Server settings under Fog Settings in the GUI and it notes the PXE Kernel Directory being /var/www/fog//service/ipxe/. I checked the permissions on that folder, and they appear to be limited to a www-data group? I’m not sure if the FOG service account is joined to that group by default or if I need to update permissions there? I didn’t see anything about it in the Wiki.

Thanks @george1421 . I followed the tutorial to do as you stated. There is now a matching password in .fogsettings, TFTP settings, and in the Storage Node configuration. I re-ran the installer with no errors at all.

I logged back into the GUI and attempted a Kernel Update again, and I am welcomed with the following error:
Type: 2, File: /var/www/html/fog/lib/fog/fogftp.class.php, Line: 707, Message: ftp_put(): Could not create file., Host: [IP Address], Username: fog

EDIT: Redacted the IP Address; completely missed that it was included in the error.

Apologies for the double-post, but the tutorial @george1421 linked suggests that I copy/paste the password from the .fogsettings file. In my first post, I noted that I changed the password in that field already as well. Note that this is from instructions on the Wiki when changing passwords, so I figured this was the procedure (and in previous versions of FOG, it was). Now that this has changed, perhaps we need to take a different approach (and update the Wiki please!).

Considering that the password has been updated in Ubuntu, .fogsettings, the Storage Management page, and in TFTP, is there another way to restore this?

Well just to point out briefly that FOG didn’t break at any point, it just simply didn’t work for a new machine. It still worked great for other machines no problem. It’s simply a brand new model that we don’t normally work with, which is why I assumed the kernel needed to be updated – we had done that a few times in the past, as we’ve been using FOG for many years here, and it typically resolves our problem.

I’ll follow your tutorial to get things back up and running and report back. Also pointing out that I’m on FOG 1.4.4, so not sure if that service account bit is relevant in my case.

Hello everyone,

In trying to update the kernel on my FOG server, I was greeted with a credentials error. I apologize, but I did not capture that error and am unable to get back to that state after attempting repairs. I may have made this whole situation a lot worse, I’m not sure.

In trying to troubleshoot the credentials issue, I started updating passwords to match the login for the GUI. The FOG GUI login is just the default with a username of fog and a password of password. That account could not login to the server with those credentials, however, so I updated the server’s account to match that. I then updated the Storage Management area to match that password and also changed it in the TFTP settings to match there. I then changed it in the .fogsettings config file as well.

Now, when trying to update my kernel, I get the error:
Type: 2, File: /var/www/html/fog/lib/fog/fogftp.class.php, Line: 707, Message: ftp_put(): Could not create file., Host: [IP Address], Username: fog

I noticed that many of those passwords that I was updating appeared to either be randomly generated or possible done in FOGCrypt? I’m not sure tbh.

My FOG version is 1.4.4 SVN Revision 6077.
The OS on this server is Ubuntu 16.04.3 LTS.

All has been working fine until today when trying to image a new Dell Precision machine, which couldn’t get through FOG Registration, so we started with the Kernel update as the next step to resolve that issue. And as a result, I have created more problems than I’ve solved. If we can get the Kernel update errors resolved, I think I can go from there.

Thanks in advance for any support!

EDIT: Redacted the IP Address; completely missed that it was included.

@Wayne-Workman Thank you for reporting the bug. I was able to find the logs I needed using the SQL commands you provided. Thanks a ton! Hopefully the bug gets resolved soon.

@Wayne-Workman Yes - these were all from Multicast tasks, which require registration in order to create proper groups, if I recall correctly.

Server

• FOG Version: SVN Revision 5773
• OS: Ubuntu 14.04

Client

• Service Version:
• OS:

Description

I’m trying to pull up some reports of imaging that was conducted back in August to see what the timeframes were, in order to make comparisons with recent network upgrades that occurred - the purpose is to help show that network upgrades have been valuable in increasing efficiency in PC deployment for our organization. But when I log into FOG and go to Report Management -> Imaging Log, It allows me to select a Start Date as far back as 11-12-2015 and an End Date of today. I can select any date range, and each one gives me “No results found.”
We upgraded to this SVN revision back in June. It was working prior to that upgrade. Am I doing something wrong, or is there a problem I need to fix to get reporting running again?