@wanderson Those “last insert ID” errors are almost always fixed because:
https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy
That said, when updating, you probably need to refresh the page (after ensuring the DB is usable).
@wanderson Those “last insert ID” errors are almost always fixed because:
https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy
That said, when updating, you probably need to refresh the page (after ensuring the DB is usable).
@x23piracy It’s not on THAT host. It’s from a common mac from other systems that are sending a MAC that IS on that host.
@x23piracy IT HAS NOTHING TO DO WITH it4313
It has to do when a mac address that IS registered to it4313, but being presented from the other systems.
Goto:
FOG Configuration Page->FOG Settings->General Settings->FOG_WEB_ROOT
Change from WEB_ROOT
to /fog/
, boom presto success.
I would suggest updating first. It’s been a while, but I believe there was a bug with this that I’m pretty sure has been corrected for.
The part that’s important, however, it’s not restarting to change the hostname. It’s restarting because it thinks there’s a task for it to complete.
That /opt/fog/.fogsettings file, pelase edit the snmysqlpass line to make it match what you “know” what it is. THen rerun the installer. Apparently it got changed at some point in time.
@UWPVIOLATOR I’m sorry I’m not 100% on the way the client does the hashing. I know we do test things, but it would seem maybe it can’t write to the same point on the client machine and is coming up with a sha512 hash of 0 byte file? (No I don’t expect you to have the answer).
@Wayne-Workman We ran through manual hashes and the fog server hash is correct. I haven’t seen a client hash fail except under relatively certain circumstances.
I’m just guessing, but maybe antivirus is quarantining/removing the file before it is able to be checked. Maybe there’s a content blocker not allowing the file to pass to the client?
@Joe-Gill I’m confused.
The server you’re trying to have multicast is not the server you’re looking at the logs on. So of course the “fogserver” server is NOT the master node right?
I don’t know why this was reported like this should’ve been fixed already. (No I don’t keep track of all Distribution release dates.)
I’ve fixed, and tested, the installer under Debian 9 RC-4. Knowing Debian tends to be very stable, I think this is suitable enough.
The working branch contains these fixes if you MUST install fog on Debian 9.
Can you show us the powermanagement information for this particular host as seen in the GUI?
@jheikkila54 Can you make sure nfs is running?
service nfs-kernel-server restart
OR
service rpcbind restart
service nfsd restart
service nfs restart
I know you’re running centos and all but i can’t remember what is what so just try the whole thing.
Also please check that firewall isn’t running.
What didn’t solve what issue?
You need to provide information other than, it didn’t work. If the solution from the thread was identical to the issue you were seeing, then did you follow the information exactly? If the information from this was not identical, you likely have a totally separate issue.
@jaoyer So it’s safe to solve this thread? Sorry I didn’t poke my neck in. I didn’t notice the / in the image path as passed either.
Glad @george1421 and @Sebastian-Roth were able to help.
@Sebastian-Roth This is really possible. The “feature” is to allow you to put images into sub folders of the root images folder.
I found the issue and fixed it in 1.4.3. This problem was a correction to fix the “cannot set DOW to 0 and/or 7 as the client expects it to be 7.”
This should be more appropriately addressed.
So I’m not seeing any problems with user logon. I did see an issue with powermanagement and while I was looking into that, I did notice user tracking appeared to be doing what was expected.
Can you provide the fog.log of a machine that’s not sending the user login/logout information?
Oh, even simpler, Turn off “Task Reboot” on the hosts client/service settings. Or even better, just turn off the “force” reboot portion from FOG Configuration Page->FOG Settings->FOG Client - Task Reboot->FOG_TASK_FORCE_REBOOT
The hosts won’t magically try to reboot to perform the task in question.
How did you delete the images initially?
If you delete the images individually (clickon on each image->choose delete) it will ask you if you want to delete the data as well.
If you deleted using the “list/search click checkbox press delete” it doesn’t do this option yet. I’m nervous about adding this capability here and the best approach to handle it just because you’re dealing with real data, so I hope you understand the hesitation.