@Malos said in SVN 4380 Cloud 5419 (on Ubuntu 14.04.3) - Fog Client (404) Not Found.:

Here’s the fix, just needs to be run once install.sh has finished completely:

Make a symbolic link at /var/www/html for fog, and point it at /var/www/fog

ln -s /var/www/fog /var/www/html/fog

Ta-da, no more 404s!

Thankyou!!!

All fixed and pushed.

Found another typo, sorry. Been doing a lot lately.

Should now be fixed properly.

Sorry, yes. Go ahead. Thank you both 🙂

@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).

Tom was able to get this fixed, and I’ve confirmed it’s fixed.

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.

@Sebastian-Roth said in [SVN 7009 FTP errors after image capture: Updating database failed:

@mr626 Take a look at the installer/git/svn directory. There should be …/bin/error_log/*.log with revision number in the filename.

Good tip, but unfortunately I cleared out the svn folder prior to the last pull that I did (troubleshooting an unrelated issue).

Sorry.

@george1421 You can solve it, I will reinstall my distrib tomorrow

ok no problem, thank you.

Added this “feature” to the report page now.

It will allow you to approve/delete (selectively as well) pending macs from this page.

It will, most likely, print the checkboxes and form information with the PDF, but it should still be okay.

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

@Wayne-Workman I’m already looking at it.

Because of what you reported, I’m working on a hopefully better approach to getting the dumped out file.

r7001 this appears to be fixed.

Confirmed, Found, Fixed, Tested, and pushed.

Thanks for reporting.

@Hanz Confirmed, found, tested, and hopefully fixed now thanks.

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

this is STILL working. lol. r6967