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

@george1421

For clarity the command Tom provided didn’t return any value, but it did set me on the right path (so to speak).

Well its not as clean as I hoped, but this command will return what I want.
find /ntfs -type d -iname "sysprep"|grep ystem32

For what ever reason sysprep exists in System32 and SysWOW64. Either way the above command will return the proper case regardless of the target OS.

[edit] And this command will find the proper unattend.xml regardless of the case.
find /ntfs -type f -iname "unattend.xml"|grep ystem32
[/edit]

@Tom-Elliott Fixed!