@Omanimous Without knowing the exact details. A 128GB disk (ssd or hdd) from two different manufacturers are usually different sized down to the byte level. So in theory if your source disk is one byte larger than your destination disk a non-resize FOG image will fail.

I can say for my reference image (which I deploy to all hosts), I create on a VM with a 40GB hard drive. That way I’m assured it will deploy to all hardware on my campus. For win10 I use a 60GB reference image.

With FOG 1.2.0 I used non-resizable and then let windows expand the disk. With the 1.2.0 trunk build FOG expands the disk now. I still use a 40GB reference image for Win7. So I always go smaller to larger when the image is deployed.

@Sebastian-Roth I’ve not heard a thing from that building’s techs about this issue. If they try to get this model working with FOG in the future, I’m sure they will Google search it and find this thread, wouldn’t that be humorous?

I’m working with one of them tomorrow, I’ll ask about it.

@Wayne-Workman said:

I’m convinced this is a network issue.

+1 from me!

@Sebastian-Roth

I tried imaging and it works! Thanks for all of the work you guys do!

Thanks for the reply Sebastian and sorry for the super long delay.

I am observing this behavior when using “ipxe.pxe” – I have not used any other one binary (not since I switched it to a production server a couple months ago).

Also, to clarify, the transfer rate is good once the transfer begins, it is only when it is “configuring net0” that it seems to be a slow link. However, I assume it is some hardware dependent issue as I just tried a random computer model and saw it was configuring at the expected 1Gb link speed.

So I guess the tl;dr is that this isn’t really a problem.

@Sebastian-Roth The latest build worked. I’ll try and put this in a new thread later today.

@Sebastian-Roth Just for reference: I could never make that work correctly on 2008. I may have missed something or two, but I messed with trying to get it to work for a day or so and gave up. Maybe someone else better than me can get it working.

@Quazz @george1421
Thank you both for your answers, appreciate it. I started with the easy solution suggested by Quazz, and it fixed it!
Now running trunk 6677 and the registration just works fine!
Thanks a lot.
Next time I have a problem, I’ll update first, then post on the forum 🙂

@Sebastian-Roth Doing my best. 😉

Marking this solved as I am absolutely sure that using newer kernels will make this Intel i210 NIC work!

I am solving this as others were able to capture and deploy on those HP stream 11 gadgets with the most current version of FOG trunk!

Ok, marked as solved for now. People who want to keep following, see here (mind this is about PXE booting a Surface 4 now).

Thanks for reporting back. Moved to “Hardware Compatibility” section and marking it solved.

@Psycholiquid Oh, ok. I think I might suggest trying to capture your image using different OS types - specifically Linux. See if that works.

Thank you guys! It seems to be that GPT Problem. After doing the fixparts command and deleting the GPT entries now I can upload the machine 🙂

Hopefully deploying them will work in the usual way 😉

THANK YOU!

Sort of a side note but advanced task debug download/upload should also now work properly.

@Aaron-Kearns said:

However, that SOMETIMES works and other times does not.

What exactly does that mean? Can you please take a picture when things go wrong andupload it to the forums. There is no chance we can help you if we don’t know exactly what goes on.

So SSD does not want to play with FOG from what I get. Please try booting any kind of live linux DVD (e.g. ubuntu) on the 3020 with SSD installed. If this comes up please run commands lsblk and cat /proc/partitions - take a picture for us.

Upgrading to trunk might fix this for you but I can’t tell for sure.

@Wayne-Workman I believe that would be a right thing to do.

@george1421 @jloke

Here’s a DHCP class example I just made up to match the example I posted below.

class "Legacy-Specific" { match if substring(option vendor-class-identifier, 0, 32) = "PXEClient:Arch:00000:UNDI:002001"; filename "undionly.kkpxe"; }

Of course, the ending bits will be different for others, and you’d want to set this class above the other legacy class so that this matches first and the more generic one matches second, then you’d set the filename you want.

Thanks for letting us know! I am so glad that this has been fixed now.