@Tom-Elliott said in Imaging log not displaying logs:

Confirmed and fixed in latest.

Yes but now all imaging tasks are seen, not only those between start and end date

And in snapins log, only today log is correct.
With a start and end date, even if they are the same, result is not at specified dates

@Tom-Elliott said in Log Viewer doesn't list all logs due to number of storage nodes:

Logs are only pulled from “master” locations, and only if they’re “enabled” too.

That explains it. Only all the masters are listed. Thanks.

@Wayne-Workman Yep, and this is also fixed. The files and folders remaining was from order of it doing things. Once it caught a directory of either . or .. it returned without finishing.

The F12 thing didn’t work for me. Ctrl + F5 seems to work.

I probably should have said this earlier but,

at my building, we have a stand-alone fog server. The bandwidth chart for it works perfectly as expected.

At our administration center, we have a large fog setup. The main server has two storage nodes defined for it, and there are 14 other storage nodes that are elsewhere but managed by this main server. Only one of the main server’s storage nodes is “graph enabled”. All other remote storage nodes have their graphs disabled. This is the system with the graph issue.

Replying to this older thread with a newer article: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

@Sebastian-Roth Of course that’s fine. You help exactly where it matters most, and that makes a big difference.

@Wayne-Workman Nice! I haven’t had to do a batch of those 4’s in a minute, but more are coming soon. My boss was perplexed at how seemingly complicated it was to get the Pro 4 to netboot/image (USB Hub was the only way to do it). Thanks for the good news!

I’ve removed Arch Linux from the automated tests due to complications within Terraform. These issues were sort of the final straw in my Arch testing efforts.

The Arch community doesn’t supply an official AWS AMI. I had been relying on a privately built AMI that isn’t 1:1 with a manual Arch installation. For perhaps the last half year, my Arch tests were failing but the installer worked if you tested it against a manually setup Arch installation. This can only be due to differences between the AMI I was using and a manual installation.

The Arch community is vehement about only providing help if you follow their installation instructions on their wiki exactly. Because of this, when I asked for some help sorting out the issues, they were not willing to help.

Until someone with some Arch prowess can put some time into helping with this, Arch Linux will not be included in the automated tests.

@Wayne-Workman I’m not saying you all are.

I’m saying how I might approach the situation from a personal mindset.

I feel I should add all Enabled nodes will send wol. Non enabled won’t cause they’re not enabled lol.

Should be fixed in latest. Please test when you can and let me know.

@Wayne-Workman you might want to use systemctl -l status mariadb as it will give more direct errors to what caused it to die to begin with.

@Tom-Elliott 53 and 54 were fine.

@Joe-Schmitt this was an accidental issue I think on my side as it was sending wol tasks. Just for confirmation the client is simply checking if a task is reboot, if not it sets up as shutdown?

I’ve removed wol tasks from the client sender for RC 11 just would be good to know for sure.

Is it possible to solve this thread yet?

I ask because I worked on a few systems last week, and they all seemed to have been getting their information and things appeared to be setting properly.

The noted items was if I manually stopped/started the FOG Service on the machines, the default printer setting would not happen, which is (as I recall it) expected as the default setter happens via the FOGUserService, not the FOGService element. When you manually stop the FOGService, the FOGUserService is closed to, but on FOGService start (manually) the FOGUserService is not automatically restarted.

Just tested from group and all worked properly

My fault - I was ssh’d into the wrong server… 😕

@Wayne-Workman I assure you it is fixed and no having to pull twice makes no sense. It seems to me you’re still onbthebworking-RC-9 branch which has been deleted.