So now just for explanation: what could be the problem here?
There is no simple answer to this as you are describing various different issues. Let’s see if we can tackle those one by one. It might be wise to open new topics in the forums as we go along to focus on the different issues and not loose track. Depends on how dare you are so solve all of them.
this week at work we wanted to upgrade 2x Acer Z3-605 AiO from 500GB HDDs to 240GB SSDs. Systems were installed with Win10 with GPT partitioning and UEFI boot.
We tried file ipxe.pxe with IPv4 Network Stack iPXE, which resulted in restart before even downloading bzImage.
Have you tried other UEFI iPXE binaries like snponly.efi or snp.efi yet? The next step would be to compile new iPXE binaries from the latest source code to see if that fixes the PXE boot issue in UEFI mode. But we better look into the other this first.
We changed UEFI to Legacy (and undionly.kpxe) and used this with Single Disk (resizable);
That’s a good step to get around the UEFI PXE boot issue. FOG doesn’t care which mode it PXE boots in as long as it does it will start the task and do its job.
it managed to upload everything into the /images/dev folder, but the PC restarted and the task started again in infinite loop. This issue isn’t happening with other PCs, so I don’t think it’s FTP related.
Was the image moved to /images/#IMAGENAME#/ after the capture? I am fairly sure it was not. Sounds like FTP/disk space/access rights issue or the image capture ran into an issue and did not finish at all. Did you pay attention to the messages on screen when the capture was running? We need more information to be able to help with this.
We changed the Single Disk (resizable) to Single Disk - Multiple Partitions (not-resizable) and it managed to upload the image succesfully. Or at least it shows Image Size on Server now.
Better to check the files in /images/#IMAGENAME#/ on the server than relying on “Image Size on Server” information when in doubt if capture worked correctly. The non-resizable type won’t help you in this case because you can’t deploy it to the smaller size SSD.
FOG version 1.5.9 stable
This version of FOG is not yet able to capture and deploy an image to a smaller size disk if there is a recovery partition at the end of the partition layout. Find more information on this in the forums: https://forums.fogproject.org/topic/15025/move-partitions-on-gpt-layouts-need-people-to-test