Posts made by epatterson

@george1421
I’ll shut the machine down and do some checking. I’ll let you know. Thanks.

@george1421
We are using a USB, directly, attached MyBook storage unit. I then just run a move between the storage and the main machine.

@george1421
The machine I was working with had to be sent out for the user. So, I imaged another machine, with the build I had created, updated the build, and imaged back. It worked w/o issue.
Our FOG server only runs the FOG processes. We aren’t using it for anything else.
Another thought. Because our machine is an older desktop and using the original hard drive, we have to make use of secondary attached storage. In doing so, we move images back and forth as needed. Could that be causing an issue with the images, or how the database “sees” them? Should we alter the image path to the attached storage, working all processes from there, instead of moving them back and forth?

@george1421
So, saving the image from the machine to a new image in FOG worked. Could we have a database issue?
It’s very odd that we can save a new image capture, but not a capture from an updated, established, image.

@george1421
Our setup is a single FOG server, with 2 network connections.
One to the main domain, and a second to a closed network that we use when imaging machines.
We aren’t actually installing a client on the machines. They are only connected to the FOG closed network to be imaged, or to capture an image back to FOG once updated.

I am running a test currently. I have imaged a machine, I am updating it, and will create a new image category to capture the image back to the system. I’ll update the thread once I have tried imaging back to the system. Thanks.

@sebastian-roth
Good morning,
I imaged some new machines yesterday, updated their applications, etc, and ran captures, on 2 of them, back to FOG just now.
The image capture ran correctly, but the process, again, failed on the database update. Receiving a “504 Gateway timeout” again.
The successful capture Friday was on a completely new image, first time capture.
I will try looking into logs later today.

@sebastian-roth
OK. I will be doing some more testing next week. I will update the thread with results. Thanks.

@george1421
Well, holy mother of all that is good and green. The machine I just tested with completed w/o issue.

Could it have anything to do with the model, or image itself? We normally work with Lenovo T15 and/or T14 machines. However, I have an X1 Carbon that we needed to wipe prior to being sent in for repair, so I registered and inventoried it. Created a new image category, specifically for it, so we can put it back when it returns, and ran the capture.

I have another machine (T15) that I just built. I’ll try capturing it as well and see what happens. I’ll update the thread once done. Thanks for helping me out today.

@george1421
During the process, we have not had any issue accessing the site. I am able to PXE boot and register/inventory machines w/o issue. I am able to deploy an image w/o issue and monitor the process on the site from Active Tasks.

Additionally, when running a capture, I am able to monitor it on the site as well. I am testing a capture now, to get a recent log entry to look into. I may need some guidance locating the logs, as I am still learning linux. I know I have been in them before, when we had the memory issue with PHP.

@george1421
Thought the actual output might be more helpful:
sysadmin@fog:/$ systemctl status php7.4-fpm
● php7.4-fpm.service - The PHP 7.4 FastCGI Process Manager
Loaded: loaded (/lib/systemd/system/php7.4-fpm.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2022-03-25 10:11:58 CDT; 1h 7min ago
Docs: man:php-fpm7.4(8)
Process: 1141 ExecStartPost=/usr/lib/php/php-fpm-socket-helper install /run/php/php-fpm.sock /etc/php/7.4/fpm/pool.d/www.conf 74 (code=exited, st>
Main PID: 863 (php-fpm7.4)
Status: “Processes active: 0, idle: 6, Requests: 68, slow: 0, Traffic: 0req/sec”
Tasks: 7 (limit: 14143)
Memory: 28.9M
CGroup: /system.slice/php7.4-fpm.service
├─ 863 php-fpm: master process (/etc/php/7.4/fpm/php-fpm.conf)
├─1136 php-fpm: pool www
├─1137 php-fpm: pool www
├─1138 php-fpm: pool www
├─1139 php-fpm: pool www
├─1140 php-fpm: pool www
└─1556 php-fpm: pool www

Mar 25 10:11:47 fog.it.nex-tech.com systemd[1]: Starting The PHP 7.4 FastCGI Process Manager…
Mar 25 10:11:58 fog.it.nex-tech.com systemd[1]: Started The PHP 7.4 FastCGI Process Manager.

@george1421
It is listed as:
Loaded: loaded
Active: active (running)
Status: Processes Active
Server was rebooted this morning, and has been rebooted previously when receiving the error to see if that would kick it into gear

@george1421
Yup. I had seen php7.4-fpm.service in the results of >systemctl list-units --type=service earlier.
I wasn’t sure if that was the match needed.
After altering the command from earlier, I still get no results from it

ls -al | grep php7.4-fpm
or
ls -al | grep php7.4-fpm.service
The command just completes w/o any results displayed, dropping down to a fresh line in the terminal

@george1421
Do I need to run the command while an image capture is running? I get no results if I just run it in the terminal currently.

@george1421
Thanks for the response.
The error I entered is directly from the terminal when it is finishing up the imaged capture. It tries to update the database, fails, then loops through continually until stopped.

Good morning,
e have been fighting an issue with the FOG database updating following an image capture.
Previously, it was a memory issue and we have corrected that.

However, now we have a new error:
Error returned: <!DOCTYPE HTML PUBLIC “-//IETF//DD HTML //EN”>
<html><head>
<title Gateway Timeout</title>
</head><body>
<h1>Gateway Timeout </h1>
<p>The gateway did not receive a timely response from the upstream server or application.
</p>
<hr>
<address>Apache/ (Ubuntu) Server at address 192.168.3.2 Port 80</address>
</body></html>

Not being real experienced with Linux, I’m not sure the location of logs I should check for an issue. We know the apache server is running and the website is up, as we can access the site to deploy images w/o issue. Additionally, I am able to register and inventory new machines w/o issue. It is only when trying to capture an image to have a newer version of it that we run into problems.

FOG version, from the site, listed as 1.5.9.119
Ubuntu version 20.04.4 LTS

• All updates/upgrades current

Thanks.

@sebastian-roth said in Image Capture database error:

Please check the Apache and PHP-FPM logs to find out what’s going wrong

Thanks. Will do.

We are running our FOG system (v1.5.9.119) on Ubuntu v20.04.3

• Updates were run on the server this morning.
  I had imaged and updated 2 machines yesterday (2022.02.16) and ran an image capture on them to update the images in our repository today.
• The machines PXE booted and the capture process appeared to run correctly w/o issue.
• However, once the capture was completed, I am receiving an error:
  -Updating Database…Failed
  -Error returned:
  Then it keeps re-attempting to update and failing with the same blank Error.
  Has anyone run into this previously?
• I do not believe it is an error with the images, as this is happening on 2 separate machines each with its own unique image.
• I have verified the local firewall is off, so not blocking any traffic
• I have also verified that MySQL is running

Good morning,
When trying to deploy an image to a machine, I am receiving the following error:
“Unable to locate the image store (/bin/fog.download)”

We are running FOG (1.5.9) on a PC, and have updated the kernel drivers to work with our newer machines, storing images on a Synology. Yesterday, I imaged 3 machines w/o issue. Came back after lunch to image another machine and received the above error.

I have been working with one of our more capable Linux admins and making some changes to the system. I know the path the to images is correct, as we double checked it in the Storage settings and for the image itself. It’s not the image, as we tried a different image and received the same error. We verified that the path is mounted correctly.

Most of the hits I have found when searching are for capture issues. Which we are not trying to do currently. I don’t believe it’s a machine issue, as I have tried an older and new machine to test also.

Any assistance, or suggestions of settings/logs we can check, is welcome. Let me know if more information is needed as well. Thanks.