So the reason the date selector was not being seen was because I am grabbing the minimal date.

Some entries, for this field, might have ‘0000-00-00 00:00:00’ as the date time stamp, which is invalid.

So the original way it worked, if the date was invalid (start time will always be earlier than end time) it would present “invalid”.

The updated method should work for this for all of you having this problem. I’m correcting this behaviour by adjusting the start date to 2 years before the current date.

Hopefully this is sufficient. The reason I don’t want to go back further is the amount of time it would take to generate the selector. (I’m not guessing the selector based on max end date any more. I’m just giving a date range based on the earliest time found and forward (as it’s not really a selector otherwise right?))

I’m also changing the way things are displayed a little bit.

Instead of showing logs of tasks that have either an invalid start OR end date, both start AND end must be invalid to no longer show. It may make some strange readings for things, but shouldn’t hurt anything otherwise.

This wasn’t a problem with key sequence or even double entries as originally thought (though that could still cause similar issues).

However it was found and is now fixed.

Fixed in working. Thank you.

@Tom-Elliott OK, I just downloaded the image to another computer, and it works. Thanks!

And there was much rejoicing.

If you expand each option on the Fog Settings page individually, the missing bits are not visible. Only Expand ALL shows the missing bits and only at the top of the list, not where you’d expect them to be.

@Tom-Elliott said:

@AndrewC I’m not seeing the problem, but I would imagine you are seeing this in particular with EFI style systems?

Yes. It was an issue with the particular test machine. Did not have a problem with any others BIOS or EFI. Worry not.

I’d bring this to your attention:

No more recursive calls in sanitize_items function.

This was pushed up for RC-5, while it doesn’t refer to the blank page for host creation, this is what the issue was referring to. The reason it didn’t implicitly call out the create new host is because it actually impacting many other elements.

Updating to RC-5 or higher will bring this “issue” to rest for you.

@FredG I’ve added more implicit checking to the working branch to prevent this type of error.

For what it’s worth, I’ve added checking for the variables so this shouldn’t be an issue anymore.

@Tom-Elliott

Hi tom That fixed the problem, Thanks for all your help!!

@Tom-Elliott

Hi Tom,

according to the client log file it says " snapinclient module is disabled globally on the FOG Server, exiting."

I will create a new issue, and post the log file from one of the clients.

Thanks!

I cannot replicate, but that doesn’t mean much. I’m running the working branch.

Mind giving the working branch a shot and seeing if the issue still exists?

Ok.
thank you for the work done.

A very simple question, I suppose, but do the hosts that are registering have the new or legacy client?
Can you provide the client log of one of the “adding” systems? (If you are using legacy client please post one for each of the clients – one legacy client fog.log and one new client)

Oups my bad, just saw this thread https://forums.fogproject.org/topic/9399/client-doesn-t-seem-to-auto-update-stuck-in-a-loop-of-updating
It’s ok now !

Please run:

cd fogproject #if you're not in the git folder already. rm binaries1.3.4.zip cd bin ./installfog.sh

Forgot to update binaries.zip with the 0.11.9 files sorry about that.

@Tom-Elliott
Hi Tom, just wanted to make you aware whatever changes were made recently in regards to additional mac addresses have fixed this issue now in 1.3.4-RC-2 thank you.

I suspect the reasoning it “hangs” waiting for input unless only one option is defined is the timeout -1.

@Tom-Elliott I didn’t see it mentioned in the release notes hence the post. I’ll update.