@mr626 Well done. Good testing. I’ll mark this solved as the initial question is answered. Please open a new thread on the sysprep issue!

No worries guys, thanks for the clarification. As long as that is clearly listed somewhere that should be fine. Would it be worth including a small note in each release announcement along the lines of “To download this release via Git, refer to wiki instructions here <link to relevant wiki page>” ?

@adukes40 At my old job, my co-worker managed the start menu via group policy. So there’s that path.

@Tom-Elliott

Thanks Tom, I figured that might be the case I just wanted to double check.

Probably not a huge priority, but would it be worth adding something to the install script that checks to see if any schema changes are needed, and if not the step about going to the URL to update it is skipped? Or at the very least, add a notice to the step that confirms that going to the URL and not seeing a schema update page is by design if there are no updates, and that you can just continue on with the installer.

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

@MRCUR said in Recommended guide for Windows 10 image creation (from scratch) ?:

@x23piracy Are you keeping all 3 of the “store” apps? “ConnectivityStore”, “StorePurchasesApp” & “WindowsStore”?

I can’t find a clear answer on what of those three (besides “WindowsStore”) is required to make the store functional if we decide to enable it in the future. I’ve also seen it noted that “DesktopAppInstaller” may be needed for some apps to be installed through the store.

Since i use WILDCARDstoreWILDCARD i think yes because all of that apps cover the word “store”

I just had this issue as well - and it turned out to be my fault.

In the setup it asks for server and web info.

I put the IP into both fields.

I tried just putting the IP into the top server field and leaving the bottom web field alone.

When I did that, it worked.

@mr626 said:

Does the legacy client ‘know about’ these service configuration settings that are available per host in the trunk version’s web interface?

Yes.

Or do I need to update all of my hosts to the new client (which I will do eventually anyway of course)

You don’t have to upgrade to the new one, but I’d really strongly suggest that you do.

For enabling all services on all hosts, throw all your hosts into a group, and then use the group to enable all services on all hosts.

@Wayne-Workman said:

Just to make it clear, Secure Boot is currently required to be OFF to network boot with FOG. Can you provide us with a screen shot of the error ? You might need to take a video to capture the error, often times the errors are only displayed for fractions of a second. What happens if you try to boot using ipxe.efi ??

At first, I didn’t know what you were talking about–the only efi file in my /tftpboot folder was snponly.efi. But then I read another suggestion from you elsewhere that maybe upgrading to trunk might help, so I tried that.

And, lo, my /tftpboot doth overflow with efi files! So I tried ipxe.efi, and it WORKS.

Also - see my old post below on the subject of using a USB dongle.

That looks like really useful info once I get this host registered. Amazing.

As you requested elsewhere, I will experiment with co-existing EFI and BIOS hosts using DD-WRT and see if I can’t contribute to the Wiki to pay it forward.

For future readers: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

I already have a fix in place for this. In creating the pxe delete host option, I now know exactly where to go.

The file you’ll need to edit would be within the init.gz file, if you’ve already added the delete options, this will take just a couple lines of code:

When it says unable to register host as it already exists, call the fog.auto.del script, it should take over from that point, within the fog.auto.del post, it will ask if you want to re-inventory of where you can change the hostname. This should be useful, though I don’t have time to test all aspects.

Found out how to have the partition extended to cover the whole disk via this thread:

[url]http://fogproject.org/forum/threads/resizing-partition-with-windows-7-image.250/[/url]

A follow-up for those interested.

Re-uploading a fresh SOE image to Fog solved the issue: once I had done that it was fine. Still not 100% sure why I had the issue with restoring the image files I restored from backup, but maybe it could be related to the following…

I use the standard Fog backup script, which does a good job of getting all the important stuff. One thing it doesn’t backup by default though is the /tftpboot/ partition. Now, you don’t really need to back this up unless, like me, you have made changes to anything pxe-related.

In my case, I had applied the chainloading fix described here:

[url]http://fogproject.org/wiki/index.php?title=FIX:_Chainloading_alternate_SYSLINUX_to_force_boot_from_first_hard_drive[/url]

Of course, that was ages ago and I had forgotten about it…until all of our newer Dell machines (optiplex 790) started rebooting when they tried to load the pxe boot menu 😞 Once I reapplyed the fix it was fine though.

The end result is that I manually added the /tftpboot/ partition to my fog backup scrupt, just to make things easier next time I have to do a restore (hopefully not for a while!).