sorry I dont think this is an issue anymore. We dont seem to be getting it aver we updated to the latest svn. Sorry again for the non response.

@Joe-Schmitt I can confirm printer-management is working flawlessly with the new client-version.
Printers are assigned correctly, setting default printer and renaming printers is working.
Only thing I didn’t test yet is if changed config-files are recognized.

I also appreciate a lot the new powermanagement module! This is really awesome!
Thank you so much, you and the other devs do a really great work!

I just looked in the wiki, there are not spaces. those must have came from me copy/pasting on my phone.

Right now, this is verbatim what’s in the wiki, notice I put quotes around the message.

yum install git -y cd ~ mkdir git cd git git clone --depth 1 https://github.com/FOGProject/fogproject.git cd fogproject/bin ./installfog.sh echo "Now you should have fog installed."

Seems like the hardest part here was to explain what was wrong…
And fighting over who gets to fix something… that’s called motivation 🙂

@Tom-Elliott Ok I’ll look into that.

I confirm, it’s ok, thanks

@Carl said:

The original issue : yes. Should I create a new thread for the one that came up during the course of resolving that?

Yes please. Makes it more easy for people to follow…

Marking this solved.

Well, it’s been explained to me that the activity reporting is per group, and was based on which node you had selected… that was really confusing. Now there’s a selector for the group on the activity pie so I think this is a non-issue now.

This is confirmed fixed.

ok that works thanks

@Cavender I need to see the db to try to understand why it thinks there’s a hidden menu.

That said, the “login loop” issue (itself) should be fixed. I’m solving this thread. Would you mind opening a new one in regards to the fact that it thinks it’s in hidden menu when it’s not?

@plegrand Posted to the other posting. Should be good in latest.

Confirmed and should be fixed in latest. Sorry.

@Tom-Elliott all good now, problem solved.

Regards X23

Should be fixed in latest please let us know for sure though. Thanks for reporting.

@Arrowhead-IT said:

On git 7593 20 days ago upload and download caused disk 2 to go inactive On git 7961 upload works fine but download of the original intended image still causes the problem

First I want to say thank you again for all the testing you did and the detailed information. I’ve spend a couple of hours trying to find what might have caused this issue but I was unable to reproduce the same problem on my machine here. Version numbers are fine when trying to find a problem in the web gui code but unfortunately it’s not the same for the scripts in the init files because the installer always tries to download the very latest inits from the official FOG website. So if you run the same installer without updating your local git/svn repository you will have a newer code in the inits but still the “old” code within the repo. While this is not causing any trouble I just try to point this out to show you that web gui and the installer version are the same but don’t essentially match up with the version of the script code in your init files.

Don’t get me wrong. I am keen to find out what was causing this and when / how we fixed it. But this would cost me a couple more hours and I don’t have the time to dig any further right now. Please keep us posted if you’re seeing this kind of issue again.

Attached is a diff of all the changes within src/buildroot/package/fog/scripts/ in the git repository since around early April. Nothing I would assume has anything to do with the problem you had. I am really wondering if somehow (no idea how!) you had init files in place that were even older (if I remember correctly we found and fixed some issues within the calculate resize magic scripts in early 2016)…

Would you mind if we mark this solved for now?

Confirmed that it works in 8064.

@Tom-Elliott looks like whatever you did worked 🙂 thanks for the quick turn around! Thread can be marked solved.

@Quazz the extra debugging was actually an error in code base for the bootmenu which I’m pretty sure I corrected yesterday.

@Wayne-Workman

I just tried adding some real hosts (non VM), they are renaming just fine.