Oops!
I deleted from CLI. But I just did that again and the image did not appear in the list and the storage number increased accordingly.
-Jim
Oops!
I deleted from CLI. But I just did that again and the image did not appear in the list and the storage number increased accordingly.
-Jim
Hello. I have deleted old images in my images folder. However, the available storage space node never changes. How can I update this to show actual drive space available for images?
Hello team. Running into an issue. I have these new Lenovo all-in-one devices and I have opted to use the available SSD rive addon as my base OS drive, and a secondary 500gb for data. However in fog, while I can select multiple partition image, it will not allow me to make either of the drive resizable. That created big problems for me. Is fog going to come up with some work around for this? Has anyone any thoughts on this?
@sebastian-roth said in Image menu not showing recently created images:
@Jim-Holcomb How many images do you have? I am not aware of a limit of images that can be seen in the menu but I can’t tell you for sure.
So would you be able to delete an older one and see if one of the new one pops up in the menu?
Hello Sebastian - I tried that - deleting older images. No joy. You know that the image menu just keeps going to the next number in order. I am currently at 160, but of course I do not have anywhere near that many images. Then menu goes to 158 then ends. Yet if I go to “List all Images” of course the image resides there with all of it’s available information, size, date, etc…
I am stumped here.
@jim-holcomb I can deploy them manually from host, but not automatically from choosing the image from the menu. Not sure why they do not appear on the menu?
I have created and uploaded two new images for deployment, but they are now showing up on the boot menu. Any idea why?
I am getting this error nearly every time I click on list all hosts (and have to reboot)
DataTables warning: table id=dataTable - Invalid JSON response. For more information about this error, please see http://datatables.net/tn/1
Can anyone help?
@sebastian-roth
That’s true, but every time I upgraded either fog or the OS, something would break. I used to have the advantage of Tom Elliott being available to assist in these cases, but he never returns emails or phone calls from me in like nearly 2 years.
Specific hardware you see this issue happening on? Make and model?
We have mostly Lenovo machines; desktops and laptops. Stalls on both…
Have you tested other machines/hardware to see if they behave the same?
Yes laptops and desktops.
Are Host (what you called fog client) and FOG server on the same subnet or connected across subnets through a router/gateway?
The latter. For the moment, the Fog Server is connected across a vpn to another building…
Tried connecting the host as close to the FOG server as possible (same switch) to rule out network components?
Not yet - but thought of moving the fog server to this building, which is where my new office is located
Linux OS and version?
Ubunto 16
FOG version?
1.5.6.700
I have a strange situation happening. When I’m running the fog client uploading an image, during capture, it will run between 3 and 5 GB at a time, then stall for about 10 minutes then run another 3 to maybe 5 GB and then stall again for about 10 or 15 minutes and I just can’t figure out why. Anyone have any suggestions?
Well, not sure why this happened but I took the job out for the task queue and ran the image manually - this worked!
Sebastian, now the output looks like this:
find /etc -type f -exec grep “date.timezone” {} /dev/null ;
/etc/php/7.1/apache2/php.ini:; http://php.net/date.timezone
/etc/php/7.1/apache2/php.ini:;date.timezone =
/etc/php/7.1/cli/php.ini:; http://php.net/date.timezone
/etc/php/7.1/cli/php.ini:;date.timezone =
/etc/php/7.1/fpm/php.ini.ucf-dist:; http://php.net/date.timezone
/etc/php/7.1/fpm/php.ini.ucf-dist:;date.timezone =
/etc/php/7.1/fpm/php.ini:; http://php.net/date.timezone
/etc/php/7.1/fpm/php.ini:date.timezone = America/New_York
Still getting the checkin failure
@jim-holcomb said in Checkin failure?:
find /etc -type f -exec grep “date.timezone” {} /dev/null ;
Now today when running this command: find /etc -type f -exec grep “date.timezone” {} /dev/null ;
find: missing argument to `-exec’
The current timezone is EST:
root@fog:~# date
Thu Dec 10 16:29:02 EST 2020
root@fog:~#
@jim-holcomb said in Checkin failure?:
(N): The timezone could not be found in the database (In line for 10)
This has me thinking? The error says "…(N): The timezone could not be found IN the database (In line for 10)
So is this an issue with the database itself?? Seems to me it is looking for a TZ “value” in the database that is missing?
@sebastian-roth
Well nothing changed, auto updates are not on, and it worked before without the timezone settings?
As well check in FOG Configuration -> FOG Settings -> General Settings to make sure FOG_TZ_INFO is set correctly. *This is set as always to New York, no changes there…
@sebastian-roth
Running Ubuntu v16.04
No OS updates run for a few months
FoG was working last week.
@sebastian-roth said in Checkin failure?:
find /etc -type f -exec grep “date.timezone” {} /dev/null ;
root@fog:~# find /etc -type f -exec grep “date.timezone” {} /dev/null ;
/etc/php/7.1/apache2/php.ini:; http://php.net/date.timezone
/etc/php/7.1/apache2/php.ini:;date.timezone =
/etc/php/7.1/cli/php.ini:; http://php.net/date.timezone
/etc/php/7.1/cli/php.ini:;date.timezone =
/etc/php/7.1/fpm/php.ini.ucf-dist:; http://php.net/date.timezone
/etc/php/7.1/fpm/php.ini.ucf-dist:;date.timezone =
/etc/php/7.1/fpm/php.ini:; http://php.net/date.timezone
/etc/php/7.1/fpm/php.ini:;date.timezone =