Microsoft Surface Pro 4
-
Wow, this got a lot of attention after being totally silent for a week.
I think I need to mention that this is actually not about surface devices I reckon. In the last days I kept thinking about this issue and found that the problem is actually the USB NICs, not the device itself. While the host might still be part of the equation I am pretty sure that what we see (PXE boot issue on surface - and other devices - that is solved using ipxe7156.efi) is primarily caused by the USB NIC adapter - possibly in combination with the surface UEFI firmware. As far as I have seen this is always an issue with Realtek RTL8153 USB NICs.
@Avaryan Most people are able to PXE boot their surface devices using the
ipxe7156.efi
binary and we are in the process of figuring out why this particular build is working but not the current ones.So again I am reaching out to all the people. @sarge_212 , @jhuesser, @Psycholiquid, @fry_p, @Scott-Adams, @xerxes2985, @dylan123, @ecicerkofski, @Arsenal101. If you have such a Realtek RTL8153 based USB NIC could you please try PXE booting (possibly in combination with a surface device but the issue might even occur with any other UEFI PC/laptop!) using the different binaries I provide here. You just need to test 04_ipxe.efi and 05_ipxe.efi! Plus testing the binaries in the svn subfolder would be highly appreciated as well. Post your results here. Might as well try
00_efi_timer_ipxe.efi
which is a debug enabled binary. I’d really love to see the output when booting this too. Come on people please help us finding what’s causing this and get it fixed eventually. -
@sebastian-roth I’d love to do more tests, but unfortunately I don’t have an available surface. My apologies. If I get one I’ll let you know.
-
My sites IT director has the dongle from the Surface 3 sitting in his desk from when he demo’d one last year. I’ll try that next week,.
-
@fry_p Testing just the USB NIC (which you usually use with the surfaces) with a different device (even a desktop PC) might help!
-
I was able to boot to FOG and deploy an image using the Surface Pro 3 dongle.
However, upon restarting the Surface wouldn’t boot to the HDD. Unsure if I have to change some other settings. It wasn’t even trying to boot to Windows.
I booted back into FOG after imaging a choose the Boot from hard disk option, and got this menu.
edit: Maybe I’ll need to add the HDD drivers into the image?
-
@avaryan what kind of image do you deploy? (legacy or uefi and which os)
You are forced to use efi for the image, you can’t use legacy. (Surface is efi only)While you deploy or handle with fog boot stuff you need to disable secure boot.
You can reenable Secure Boot after deployment (no more fog boot stuff).Regards X23
-
@x23piracy Test environment is setup for UEFI at the moment.
I was already able to image the device, as stated above. I suspect the issue may just have been that the image didn’t contain HDD drivers for the surface. I’ve now added some of the Surface drivers to the DriverStore and will be capturing that image to test.
-
Is there any special I need to do on the FOG end with the image itself? I am able to deploy the image to the device, but that’s it. Even after adding the drivers into the image it’s still not booting to the OS.
-
@Avaryan Edit this host in the FOG web interface and try different (uefi) exit style settings in the host configuration.
-
I know this is old but I have about 40 Surface Pro 4s I have to image once a quarter. This is my setup and it seems to work:
Surface Pro 4 on MS Dock. This boots to FOG without issue.
From menu I hit Register or it goes into the imaging process on its own.
From there the NIC on the dock stops working and I have a specific USB NIC I use:
This is plugged in on the side at the same time as the dock is connected.
This NIC picks up and starts the image or registering the device.
I have to point out that I had to ignore this device in the FOG server settings so it wont show errors as multiple MAC addresses and cause issues here:
I haven’t had an issue since I went to this setup. and I am using ipxe7156.efi as my default efi in DHCP so it works for most of my workstations and Laptops. But the ARCH UEFI DHCP vendor class settings can be used also on ARCH:00007 so long as you don’t have other devices that can conflict. For instance the HP 850 G3 i210v network port.
-
I also use no exit style it just works out of the box.
-
Thanks heaps for reporting back on this…
@psycholiquid said in Microsoft Surface Pro 4:
I am using ipxe7156.efi
Yes we still have those old binaries around as we couldn’t figure out what’s wrong with the newer iPXE versions. I beg you to help us finding what’s wrong and finally get rid of those ugly extra binaries!!
Please take 15 minutes (I am pretty sure it shouldn’t take any longer) to test a couple of binaries for us as we devs don’t have those devices to test with. Find the files to test here. Please try out
04_ipxe.efi
(should work) and05_ipxe.efi
(should have an issue, hanging on init.xz) and report back. Then if you have another 20 minutes, please also test the binaries calledsvnXXXX_ipxe.efi
and let me know which ones work and which don’t. -
NOTE: I moved all the posts about testing the iPXE binaries: https://forums.fogproject.org/topic/10789/boot-file-testing-for-sr