For future readers, there is a post in this thread that details how to do this for the legacy client: https://forums.fogproject.org/topic/5996/svn-4972-to-svn-5046-server-load

I believe that for the new client, it is able to auto-adjust when the checkin time changes.

Fixed
But new issue now - maybe better for another thread - php requests are slow to load now (including /fog/service/ipxe/boot.php - which sometimes times out)

@Trevelyan Figured out the problem. There was an old debugging line added unintentionally. It has been fixed in the latest.

@Trevelyan The only way to find out is to play around with it.

I’d suggest first creating a single partition disk resizeable image - and then just specify in the host’s general properties which Host Primary Disk to use. To find out what that is for the 2nd drive, boot into a debug upload task, and just find the name that fog uses to refer to the 2nd disk. It’ll be in the devices virtual file system ( /dev ), it’ll likely be /dev/sdb but you must look to be sure. Specify the correct Host Primary Disk in the host’s properties page and then do an image capture as usual.

Then try to deploy that image to a test machine (not your golden machine) and just see what happens. Make sure you specify the Host Primary Disk parameter for the test machine.

If that works as you want, try it on a different model test machine, with maybe a different sized hdd in it. See what happens.

Please let us know how it goes and what you learn.

Errors (or warnings as the case is here) does not mean anything in particular. I’m adding checking to return if the value is true, and throwing an error if the value is false. If the error is thrown, it also returns false. My guess is this is specific to when you’re inserting, or updating, and entry and this is why you’re seeing this error. I’ve added, as I stated earlier, a better check mechanism so it will simply return if the value is true and not attempt iterating over a boolean value.

4806 Should have this ready and working for you.

this problem is believed to be resolved now, thank you for the bug report.

Fixed in v0.9.1.

@Trevelyan Do you mind hitting me up through chat?

I think I know a fix. My guess all of the systems have a VM system installed on them? Because of the imaging process, they all have the exact same NICs for the VM system. What I’d recommend is to set the two macs on the filter list so those two macs don’t get added/readded through subsequent registers.

This meaning, add the two 00:50:56 (you should be okay with just that much of the mac added to the filter, approve these two nics and delete them after approving them.

They should no longer continue to register (hopefully if SVN is working properly) and all your other hosts should (if using the new client) register themselves into a pending state, or do nothing at all because there’s no mac address associated with a host.

@Wayne-Workman said:

the WiKi SVN article somewhat promotes upgrading to the developmental revisions…
I really think that the other upgrading methods should be ditched, IMHO. But others here feel otherwise.

I very much agree. There have been so many major fixes, changes and improvements, that anything less than SVN (3410 in my case) is hamstrung by comparison.

Sad truth is, although Tom is fuc**** awesome at what he does, he is largely a one-man-army and he has a full time job and wife and so on. He’s the driving force behind FOG.

Indeed 👏 👏 👏

@Wayne-Workman

They aren’t static, but they do retain leases for a long time. At the campus here, the ICT services department control the DHCP server that gives our machines their IPs and the DNS servers. We have some control (over AD groups and users and group policies and - to a degree - our switches and physical infrastructure) but not when it comes to DHCP/DNS operation. So we are stuck with IPs.

Which is fine, we can find which PCs are which IPs. I would have thought that a host could identify itself when the FOG service first starts and update its record that way, but I wouldn’t have thought NetBIOS pinging was really the way to go for communication with hosts when IP and MAC addresses are used for everything else.

It’s very common on Ubuntu. Others on other systems have occasionally ran into the issue also. I know on Fedora Workstation 21 in Hyper-V, I had the issue. But with Fedora 21 Server in Hyper-V I don’t have the issue.

It’s just all about the timing, really.

And yes, that post you found is how you’d fix it.

And, there’s no reason to put up with having zero logs. Different systems experience different problems. For some, imaging doesn’t even work unless you make those services wait for a bit.

[quote=“Trevelyan, post: 47309, member: 7471”]Is it just avoiding possible data corruption, or certain data corruption? I haven’t seen any ill effects of not changing, to be honest. I’ll keep going without changing it but keep it in mind anyway. Thanks for explaining it! :)[/quote]

potential.

the snmysqluser and snmysqlpass should have content, but it is not required. If you have a mysql password set, at the least you would need the snmysqlpass to assist when upgrading from a previous install. It not existing under normal circumstances shouldn’t affect the running of fog.

A similar thread to this seemed to die - if these are broken, the wiki should be updated with that…

Ah cool, there hasn’t been a client update in a long time, right? What’s the plan for it?