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

@Tom-Elliott Actually, the issue just appeared on our big fog system, too. And after refreshing the page, that too disappeared.

0_1470939151452_upload-2973df0c-a05c-4a51-92e1-db1d1949078f

@Tom-Elliott Yes. Thank you.

Fairly sure we got this figured out tonight. I’ve added the changes to the head state of svn and git so the fixes are now a part of 1.3.0-RC-8 so no need to wait.

Thanks @Wayne-Workman for the teamviewer which helped us narrow down what the issue was.

For all following along, it basically boiled down to file hashing taking far too long on large files. The checker would fail if the script took longer than 30 seconds and would also fail if the connection time was too long. It would also fail if the connection time was too long (timeout was defaulted to 15 seconds). So by default, if large file was not hashed within 45 seconds, it would fail the snapin completely. The fix, for simplicity sake, is to allow the hashing call to run unlimited and increase the connection timeout to a day. This could’ve been fixed had I kept a hash within DB, but I have a hard time trusting it as if somebody manually updates a file it would always fail the hash.

For Huge snapins (> 5gb) I’d recommend installing the software in your image rather than rely on the snapin system to install them. I say this, because even without hashing, having such a large file (especially spread out to many hosts) will create a lot of bandwidth usage (leaving the server less to perform imaging with if needed) and would be called that number of times to start transferring the file. Add in the hashing (which is another way The client and server help prevent bad files) and you have one big mess of Load and IO access issues.

Both of the selector issues are fixed in RC-9.