I have configured two nodes with 5 max. clients. The result should be 10 free slots in the dashboard.
But the dashboard only shows 5 free slots.
When the nodes have unequal number max. clients (e.g. 4 and 5) the free slots where sum up correctly.
@andyroo54 I’ve added error checking for getting the $_FILES[‘blah’][‘error’]
The problem, in the case of too large a file chosen, is it completely blows away ALL $_POST/$_FILES variables as blank. This is why it’s reporting the “blank name”.
Unfortunately there’s not much I can do to fix that.
I have also added the suggested 3g limit instead of 100 megs. Of course, it won’t change this if your values have been set to other the the 8m (post_max_size) and 2m (upload_max_filesize).
The updater script was never compatible with trunk. However, (drum roll please), it is now.
You will have to update your sources first but all should work.
Of note, I have a check to see if you’re trying to install trunk. If this flag is not specified it assumes you want the latest stable version. To keep trunk upgraded add trunk='yes' to the /opt/fog/.fogsettings file and you should be all set.
I’ve solved this thread for a couple reasons. First, this isn’t really a “bug” in the truest sense. While it did print unwanted data, it had literally 0 impact on the operation of things. That said, the second reason is these “suggestions?” have been achieved. First, I added the rootfsext=ext4 as suggested. Second, we are not starting udevd at boot any more. The findings (as far as we’re aware of) that udev did “special” was it linked the stdin, stdout, and stderr to their respective proc resource element. We were able to do this on our own without needing to start this udev script at boot. This means you should not see the epoll message at all anymore.
@Tom-Elliott I’ve used it lately on a low-resolution monitor and an older computer in a debug session, and I’ve noticed I can’t see the bottom line where you normally can see where you type in commands for Vi. It’s like the screen is mis-aligned or something. Of course, paying very close attention to what you type and knowing what your doing and you don’t need to see that line, but still it’s weird. Mind you, that low-res monitor works perfectly fine with showing the bottom line at the shell prompt in a debug session.
Oh you know what? I just figured out why this happened. blah.
I was just talking to Tom and he asked to see if the /home/fog directory existed.
It doesn’t. Why? Because I blasted the entire /home directory this morning because all those fog backups in there was crashing the server… rm -rf /home/* Yes sir…
I fixed it with
mkdir /home/fog;chown fog:fog /home/fog
@jayphizzle What I think you’re seeing, unless you compiled your own version of the FOG Client for 1.2.0, is the OEM Keyed systems automatically activate themselves if the Product Key is not set in the unattend and SLIC is detected. FOG 1.2.0, by default, did not have a Product Key activation system. I don’t know what kind of issues this would cause with a client that actually can use the key, but I’m imagining it doesn’t work the same way as what would be normally expected.
