Here is my example of the unattend.xml file and sysprep commands. https://forums.fogproject.org/topic/11920/windows-10-1803-sysprep-problem/7

The unattend.xml file is used on the other side of sysprep to build the target system, its not used to build the golden image. Since you are just getting started with Win10, you have a long way to go. You won’t have the flexibility in customizing the image as you had with Win7. At times you will go mad trying to tweak the win10 image into doing something simple (like when adobe acrobat is installed, but win10 insists on using edge to display pdf files).

Also a great resource for building golden images is the Deployment Research web site. There is a lot of great examples there you just have to dig for them a bit. https://deploymentresearch.com/building-a-windows-10-v1809-reference-image-using-microsoft-deployment-toolkit-mdt/

@JJ-Fullmer said in issue with netcard of dock gen2 of lenovo l390:

Any reason you didn’t want to try compiling kernel version 5.1.16

Well there are a few reasons.

1. The 5.1.16 kernel is radically different than 4.19.65 and it hasn’t been fully tested with fog and imaging. It was created to see if an updated kernel would address a slow nvme imaging issue that impacts a specific nvme drive. It didn’t resolve the issue by the way.
2. FOG 1.5.7 (the latest GA release) ships with 4.19.64, I wanted to build one off kernels using the kernel version closest to 1.5.7 release so if we have a difference in operation we could tell if it was the one off kernel or something within FOG.
3. The config file on the fogproject github site is configured for FOG 4.19.64 it would probably work on the 5.x.x series, but sometimes the linux folks restructure the kernel and retire some options and bring on new options requiring different parameters.

The intent of me building these one off kernels is to test new ideas and see if certain hardware need specific changes. Its possible based on testing these changes can be integrated into the FOG main line kernel. If I go off willy-nilly on my own using random bits it would be impossible for the developers to reintegrate these changes back into the main line kernel.

I know it was a long answer to a simple question, but the intent is with a specific purpose.

@Baessens We there is nothing wrong with what there. What I see is a different version of undionly.kpxe for FOG 1.5.5 and 1.5.7. So the recommendation as a test take undionly.kpxe from the working FOG server and copy it over (renaming the original first) to the not working fog server then pxe boot.

If the problem goes away on the not working fog server then the problem is with undionly.kpxe if the problem stays then its with the different version of hyper-v

@Baessens Well I must have just had a senior moment. The pxe boot files you want are in /tftpboot The path I gave you was for FOS Linux. We are not that far yet. tftpboot is where iPXE boot loaders are.

@Baessens So the point at which its hanging is when iPXE is transferred to the target computer. Nothing else with FOG is in play at the moment.

So it may be the version of undionly.kpxe that is working vs not working at the other location. Or the version of hypervisor being used.

So a quick test would be to copy undionly.kpxe from a working site to a non-working site. The files are in /var/www/html/fog/service/ipxe directory. Lets start here and see what happens when the file is copied.

Well I see a few things that are wrong or just make me scratch my head.

I don’t understand this path:
/media/administrateur/images

The default FOG storage location is /images

So I need the output of the following commands

lsblk
df -h
showmount -e 127.0.0.1

Lets see the output of those commands to decide what to do next.

@JJ-Fullmer Yes until the next thing goes wrong.

That wasn’t meant to sound bad. Its all part of kernel development. As new hardware comes out the drivers need to be updated to accommodate the new hardware IDs, even if the new device is exactly the same as the old devices.

So just to roll things up what was done with this kernel.

1. Activated the usb-c code in the kernel.
2. Updated the realtek 8152 driver from version 1.9.9 to 2.12.0
3. Added the microsoft 8152 compatible hardware code to the downloaded r8152.c file
4. Recompiled the kernel using FOG configuration base file against the linux kernel 4.19.65.

@JJ-Fullmer I just added the microsoft hardware ID to the downloaded realtek driver per Sebastian’s request in the linked thread. No other changes were made.

@JJ-Fullmer Ok well I added it because it wasn’t in the updated driver from realtek. As long as the hardware chip IDs are the same it should work no matter what model the dongle is.

https://drive.google.com/open?id=1RBLVzsFmXfTrn1sG0GE18usD-QOBs7Y6

File name is bzImageRT2

@JJ-Fullmer Ah I see: https://forums.fogproject.org/topic/10943/surface-pro-4-registration-issues/25

045E:0927 == realtek r8152. There are new fingerprints all over that driver. Let me see