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

Thanks again Tom!

Well I ended up doing a fresh install of FOG (wiped existing FOG files and set it up again) and during setup I provided the password for MySQL this time. I have a GUI, so I’m going to continue testing and see if I hit any other issues.

I will do my best to figure this out! Thanks for the start.

Cheers.

@Tom-Elliott said:

0.0.0.0 just means to use any interface.

I believe just :69 means to use anything, so even if network is not up when it starts, it won’t crash simply because network does come up.

WiKi updated to reflect this: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_TFTP#Ubuntu:

/tmp/pigz1 is a temporary location where data is streamed for compression/decompression. that part of your system seems to be running fine. what it sounds like, however, is that your drive is not being re-sized to fill the disk after imaging completes.
what version of fog are you using?
i’m assuming this is a resizable image, is that correct?

thanks Tom, that has us up and running!

I’m solving this thread. It was caused simply because I overlooked a while loop. What was a while loop should’ve simply been an if statement. Basically it was looping as long as poll was invalid, which if the connection is dropped (such as the case during an upload task to change from one checkin to another element) would cause it to loop repeatedly forever because the array no longer existed.

This should now be solved and I’m sorry. Version 4264.