@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.

So it’s safe to solve?

I was able to, more or less, replicate the problem albeit in a different sector failing. I don’t know why this is failing unless the ext4 utility used to build the filesystem has a difference from what is normally used on the likes of Redhat, Debian 8, etc…

I don’t like the way I’ve worked around this either. It leaves too much potential for unknown issues, but I think it might work for our needs either way.

I’m approaching the problem by:

Check the filesystem as normal. Copy the error so we can present it to the user later if needed.
If the filesystem check fails as it seems to do, attempt to forcibly fix the problem. If the forcible fix doesn’t seem to help, then we know there must be a real problem. I’m still waiting for the upload to complete to find out if it works. Then I’ll test if deploying the image works as well.

And success.

If you’d like to test for yourself, please download the newly built inits (these will be in 1.4.5 of course).

It does appear to take longer to boot than one would expect under normal conditions, but it DOES boot. I’m going to try recapturing now that the init’s have been updated.

To test for yourself, please try:

wget -O /var/www/fog/service/ipxe/init.xz https://fogproject.org/inits/init.xz
wget -O /var/www/fog/service/ipxe/init_32.xz https://fogproject.org/inits/init_32.xz

Host Kernel is not IPXE Booting.

So the HDD moved around fails continuously? Maybe firmware on the one machine that’s just “not” working?

This still doesn’t feel/sound like it’s something FOG’s doing.

@Tywyn it only uses ifconfig if needed. We try ip addr too

Please run in mysql:

DELETE FROM groupMembers WHERE gmHostID IN ('', '0', 0, null) OR gmGroupID IN ('', '0', 0, null);

So updating FOG is fixed? Can we move the next issue into a new thread so as to keep things more direct/distinct as to issues encountered and what not?

I’m confused by this posting now. Sorry if this seems rude, but it sounds like you’re no longer having an issue with “Failed to update” anymore.

@Dark000 For your own needs, I’ll say, open the file: /var/www/fog/lib/fog/wakeonlan.class.php

At line 70 insert a newline after $mac->wake($SendTo, self::$_port); that reads sleep(1);