I had to republish rc 8 which pushed svn up one but I did not update the svn version because it would not have matched git. This is to be fixed when rc 9 is released.

@syschuck But I can guarantee the comment is done with a ‘#’ anyway.

Unless the files are not interchangable.

Just to help clarify, basically it was filtering the array out. Because there was only two tasks, and one of them was invalid, it was not defining the tasks as an array.

Just to help clarify, basically it was filtering the array out. Because there was only two tasks, and one of them was invalid, it was not defining the tasks as an array.

@apathetic_admin said in RC-1 Hosts Disappear When a New Host is Added:

It appears that the old host data is still in the database, so I’m not really sure where to go from here, if I should just suck it up or if maybe we can get it back.

I’ve not seen this. I’ve only heard of one other case of this, but it was during a time when the DB was plagued with all sorts of issues (because of my coding having some error or another).

This should not have happened to begin with, but it’s not something that’s a common occurrence and if it were, I’m sure it would’ve been posted all up and down the forums by now.

@Joe-Schmitt Thinking of it that way I see your point. I hadn’t considered the malicious halting but now that you mention it I could see that being a major issue. I withdraw my request/suggestion on this one. Thanks for the time to explain your thinking.

Neither of these two things are bugs in the sense that FOG is not capable of fixing them.

For UEFI boot, the escape key sequences aren’t built into iPXE. The only key sequence that is is the ESC key which is why it defaults to it.

The rEFInd config is default from the source itself, and it’s designed to allow you to configure your own needs as needed. While I could create a better config, it’s still very dependent on your own environment.

Fixed for RC-9

@Wayne-Workman I think the wake-up task must be delivered anyway. This poses no problem to simply start a station while another task is pending or in progress.

This is why the Debugger was made. Note that there is a bug in the Debugger starting at 0.11.0 with exiting so for the below instructions please use the one from 0.10.6 (https://github.com/FOGProject/fog-client/releases/download/0.10.6/Debugger.exe)

Make a snapin with the following settings:

Snapin File: Debugger.exe Snapin Arguments: user list > C:\user-dump.txt

Deploy this snapin on a problematic host. A listing of the logged in users will be in C:\user-dump.txt.

resolved with Tom’s help, boot on a debug session then type ntfsresize /dev/sda2 -f -b -P

Perfect 😉

THe slots are correct, for the time they check in.

Basically, you are playing against a clock. When one system checks in, followed by another, the queue number should change. 0 before me, typically, means that there is one system ahead of it and when that one system completes it will begin moving forward.

But lets say you’re imaging 10 systems, and have 5 in queue. It’s fully possibly two systems complete, while the other five are still in queue. One might say 0 before me already, and the others in the proper order saying 1, 2, 3, 4 etc…

But when those 2 systems complete, now there’s 2 open slots, but they’re not ready to be used quite yet. So two of the 5 systems might end up saying “0 before me”, and as soon as they can, they will start the tasking.

Also remember that there is a timeout for wait time. This is so systems waiting in line can continue on even if another system that was tasked before it becomes unusable. If we only kept in track, anything behind that one system might never get completed because they’re all waiting for that one system to complete. So some of the numbers are a bit odd.

It’s also possible that both systems checked in at more or less the same time. So both systems might say the same thing simply because there’s not a nice way to actually determine who was first or second. Partly because statements to the SQL server may take longer from one system to another (even though they’re doing the same thing).

@Tom-Elliott Thanks, that’s ok with RC8 🙂

@Tom-Elliott

Awesome. I’ll give it a try on a fresh install of Mageia5 and see how it goes. I’m not sure why it wouldn’t build the database. I turned on debugging in mysql and could see that fog was restarting mysqld in the first part of the install, but when it came time to populate the database and create all of the tables and things, there was nothing. I had a previous version of fog on this system and it makes me think that there was something left-over after upgrading.

This is already resolved, but it’s completely separate of the posting. This one is specific to hosts, and has been addressed here:
https://github.com/FOGProject/fogproject/commit/aa2184d73dc6dbb5dd513effa1fbc99e72ce768b

If you look at the last item, that addresses the host snapin checkbox issue.

@Wayne-Workman Nothing happened to it. It just wasn’t ever supposed to work that way. This is because how it works.

In either case, now it should work that way. If the client grabs and closes the snapin task too fast, it just creates a new job and tasking as to be expected.

Reworked validation for all pages and have confirmed, within reasonable certainty, that all is now validating properly. If a form using validation (Users, Hosts, Printers, Snapins, etc…) is invalid it will prompt near the box and will not allow the form to be submitted.

@Tom-Elliott Great!