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

Confirmed fixed in r6967

@Tom-Elliott Confirmed Fixed.

@Tom-Elliott I didn’t know you can allow/disallow options so easily… How about removing the “restart after completion” checkbox for snapins being deployed? The snapins area has the correct checkbox for rebooting after completion.

@Tom-Elliott sorry I have not used the right words try to correct that for next time , I know intentais help responding quickly to questions

@Tom-Elliott @Sebastian-Roth I just did a quick test with svn5107. Right now a deploy task has been running and the hard disk information has been kept. Tomorrow I’ll test some more and report back if there is still something wrong, but it looks like it is OK now.

Thanks everyone for fixing this.

@Tom-Elliott @Sebastian-Roth sorry for the late reply - I now tested it with git6907 and the display is fine now.

Also thanks for correcting the hard disk related prefixes to binary.