It sounds like it depends on the specific implementation.

For me, my source PC is on the domain and I disjoin it before uploading to Fog. I don’t Sysprep. After imaging, I don’t have to run any batch scripts or do any other authentication wonkiness. Using the Fog client, the machines authenticate with KMS and join to the domain without any further action.

Update: I finally tried manually using PartImage to pull the image with the plan to then copy it manually in to the server. In doing so, I saw that PartImage was erroring out (which FOG was hiding). Googling around found that running an fsck prior to uploading the image fixes the problem. I may dig in to the FOG code to see if I can make it automatically run an fsck prior to pulling any Linux image. For now, though, I just boot my source PC in to a live CD and fsck, then I upload the image. Works a treat.

Hopefully this will all just work better when 0.33 comes out.

Has anyone experienced problems uploading an EXT3 Ubuntu image on 0.32?

I need to get Linux imaging working with FOG. Windows imaging is set up and has been working great for months. While I wait for EXT4 support in 0.33, I’m trying to at least test with EXT3.

I install Ubuntu (tested both 12.04 beta and 11.10 with EXT3 and a swap part), set the image to single disk multi partition, and initiate the upload task. When I PXE boot the machine, it appears to go through the process, but finishes each upload instantly. It errors on the swap partition, saying it’s not supported. When I “ls -l” the /images/ directory on the server, the .mbr and .img files are there, but they are both only 6 bytes.

I have tried installing Grub Legacy per other threads, but it doesn’t help. It seems like that only fixes a problem when deploying images, anyway. I have also tried a kernel from 0.29, from 0.32, and the 3.2.4 kernel per this thread:
fogproject.org/forum/threads/fog-0-33-whats-coming.18/page-2

I get the same results each time.

Does anyone have any ideas? I would appreciate any tips and suggestions.

Is there any way to restore read-only access to the old forums?

There is a huge amount of knowledge and troubleshooting captured there. I’m running in to some issues that I know were covered in the old forums. I keep finding links to the old forums that say they have the information I need… but it’s all gone.

Could you eliminate the prompt that says “An instance of FOG Tray is already running.”? In my organization, it’s common for people to move around between PCs. If multiple people log in to the same PC using Switch User, the subsequent users will all get the error. It confuses people, and I can’t think of any purpose for the message. It seems adequate for duplicate instances to silently fail or write it to the log rather than display an error.

Also, +1 vote for finding a way to handle snapins that are multiple files. A relatively simple way might be this:
Instead of supporting only executable snapins, make it also possible to upload two files: a ZIP of the package and an accompanying script (batch file, VBS, .CMD, etc.) that will execute. The script will be responsible for unzipping the package, running any installers, and doing any other installation tasks.

Also also, I’d vote for making FOG more aggressively check that a snapin installed correctly. If a machine gets shut down or rebooted in the middle of deploying a snapin, it can get stuck as “In Progress” in the FOG console, never fully deploy, and the machine may have a corrupt snapin that only installed halfway. Similarly, if a user is running an application while FOG tries to deploy an update to it, it can fail. Making FOG more intelligently retry to deal with these scenarios would be great.

I second a vote for this. A FOG-compatible offline deploy option is on my wish list.