My only guess is the partition sets are setup in GPT, and 0.32 can’t recognize the GPT structures. Because of this, it can’t recognize the partition as ntfs and tries to upload as RAW.

While 0.32 is Old and reliable, it’s obviously not working for your needs right now correct?

I am a fan of 0.32 and understand hesitation is moving to a newer version. I would take a look at the image definition and make sure it’s not set to DD or Raw image type. I don’t think you can do Resizable without sysprep on 0.32, so if you’re not trying to do sysprep, make sure the image type os Multi-Part Nonresizable. If it’s still uploading in raw, then there’s likely something else the matter.

@Wayne-Workman said:

I’ve had this issue on both Dell 7010s and on some older Lenovos. Every now and again I’ll find a machine that just won’t image.

Sometimes, pulling the network cable and power cable and then hitting the power button a few times, then hooking everything back up will fix it. 😕 It’s just strange.

WORKED for my one Dell E6400. Very odd. That trick is used for clearing corrupt RAM and I did a swap so it doesn’t exactly make sense. Whatever…it works now.

Still working on the D630 image will be done with it shortly.

GREAT NEWS!! The re sizable image is working!! Thank you everyone for your help, and although it seems like I should of thought of that, I appreciate your time and patience with me!!
Your guys are the BEST and we LOVE your program! Thanks for sharing!
Have a great day!!

@Wayne-Workman I can also confirm that it worked for myself too. That’s how I knew about the post and I wanted to make sure to share it.

@cadyfish Thank you for your answer greatly. This post has been added to the WiKi here: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_MySQL

Since sourceforge’s issues, I decided to use git’s versioning system. This is expected.

As a failsafe, I added the same version checking to check, latest stable, svn, and git.

Maybe the syntax:

UPDATE hosts SET hostDesc=REPLACE(hostDesc,'Uploaded by batch import on %','');

i’ve only seen the “garbage” when viewing the web interface on a mobile device. never impacted functionality. i don’t think they show up on anything newer than the past year in trunk versions of fog

Just tried that and it won’t boot into debug either.

Your issue sound similar to one that I had and one that someone else posted on here. Is the hard drive size that you created the image on the exact same size? Also is the image type you are using one that is not resizable? If so, either try shrinking the partition and reupload the image so that way there is about 1-2gb of unallocated space on the drive or simply try imaging a computer with a hard drive that you for sure know is larger (not same, larger) than the one used to make the image. Hope this helps.

@rvieira said:

port=0
log-dhcp
tftp-root=/tftpboot
dhcp-boot=undionly.kpxe,fog,192.168.56.128
dhcp-option=17,/images
dhcp-option=vendor:PXEClient,6,2b
dhcp-no-override
pxe-service=X86PC, “Booting into FOG!”, undionly
dhcp-range=192.168.56.128,proxy

Try this for your configuration:

port=0 log-dhcp tftp-root=/tftpboot dhcp-boot=undionly.kkpxe,fog,192.168,56.128 dhcp-option=17,/images dhcp-options=vendor:PXEClient,6,2b dhcp-no-override pxe-service=X86PC,"Booting into FOG",undionly.kkpxe dhcp-range=192.168.56.128,proxy

Then link the undionly.kkpxe as suggested earlier.
ln -s /tftpboot/undionly.kkpxe /tftpboot/undionly.kkpxe.0

@Wayne-Workman Based on the messages from the log, I’d say this is the old client, if it’s any help.

I solved this by doing chmod777 <folder> on the directory where i put all the trunk install files and then i re-ran the installer and realized last time i ran through i didnt update the database via the WebUI When it asked…

Group ad field settings do not maintain the settings. This is because, it updates all the hosts all at once. I don’t have a performance friendly option to do this checking.

So this setting in the group field is designed to blank out after it’s been updated. The hosts within the group, however, should be updated. Is this not happening?

@skotteru What operating system?

@rvieira That’s strange, isn’t it? 🙂 Glad it works though.

Here is part of the access log for each computer and it happens every minute, not 5 minutes that I thought that I had set above.
access_log.txt

For future readers, this is most commonly an FTP credentials problem, and the answer is located here: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP#Credentials_.2F_Passwords

Coming back to confirm that the 11e image completed both up and down using the .efi extension.

FOG Trunk fully supports windows 8.1

Here are some pointers, but some of these may not be needed anymore because @Tom-Elliott has made some changes specifically to fix some of the Win8 issues that past versions of FOG had.

https://wiki.fogproject.org/wiki/index.php/Windows_8_UEFI_Imaging_Tips

You might also peek at this for handing out UEFI boot files and Legacy boot files at the same time: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence