Surface Pro 3 - ipxe issues

[Wayne Workman]

@george1421

PXEClient:Arch:00007:UNDI:003016

Either one of two things here…

Either this is not a Surface 3 but is actually a Surface 4, or, all Surface Pros have the exact same vendor class identifier.

Why do I say this? That vendor class identifier is exactly what we found for a Surface Pro 4 and integrated into FOG’s built-in DHCP configuration:
https://github.com/FOGProject/fogproject/blob/dev-branch/lib/common/functions.sh#L2020

[Tom Elliott]

@Wayne-Workman I only say that because he’s using Dnsmasq (.0). I’m not sure if Dnsmasq still looks for .0 regardless of what the filename actually is.

[Wayne Workman]

@Tom-Elliott Simon Kelly did away with the .0 thing in the version we instruct people to build I believe, mostly because it made .0 sense

[Tom Elliott]

So now that you have a working system, is it safe to solve this thread?

[george1421]

@Wayne-Workman said in Surface Pro 3 - ipxe issues:

PXEClient:Arch:00007:UNDI:003016

This really doesn’t tell you anything useful in regards to uniqueness.
There is actually 4 parts there in that option 60 value. Those values are also present in other dhcp options like 93, 94, and I think 97 (as said from a faulty memory).
the undi part on the end is the undi version 003 and I forget what the 016 is but its not unique. But in the case of this surface pro the uuid file is unique. That just needs to have a filter created for the uuid part and to exclude the sid part.

[Wayne Workman]

@george1421 the UUID is unique per device though. We were trying to find something unique to the surface pro because FOG’s latest boot files won’t work with them for whatever reason, and none of us have a Surface Pro to even begin to figure out what’s wrong.

[george1421]

@Wayne-Workman The issue/trouble is the UUID entry is up to the device manufacturer to populate. Dell does it, Microsoft must do it, Lenovo and ASUS not so much (at least with the testing I’ve see so far).

In the case of the dells there are two parts to the UUID the system ID that identifies the hardware and the right part that is the mac address of the computer (computer unique part). For the surface pro it doesn’t look like MS followed that when creating the UUID. What we would need to do is capture 2 discover packets from two different surface pros of the same model and compare the uuid part to see where the unique system ID is. I would expect the left part of the UUID to be system model consistent and the right part to be device unique part. But I’m only guessing here. MS may have done something totally different.

That is why we need the support of the people who have surface pros to collect this data for use so we can make the FOG system even better that it is today. As I posted before I’m sure the developers would gladly accept a donated surface pro 4 to help clean up a bit of theses still unknowns.

[Scott Adams]

@george1421 I will work on getting something together and post it once complete.

In the meantime, I use Windows DHCP service (not FOG’s DHCP). I simply set my 66 and 67 scope options to my fog server and to snponly.efi ( I still have to manually change this setting as my DHCP server is 2008).

I use the actual Microsoft Surface USB Ethernet adapter. I used to have to add has_usb_nic=1, but that was not needed after a particular RC (I can’t remember which one).

Also as part of the imaging, I do have an issue with using the Type Cover. I can use it in the FOG menu, but when it wants me to disconnect the NIC, plug it back in, and hit Enter, it will not recognize any input from the Type Cover. I simple plug in a USB keyboard, hit enter, then plug my Ethernet adapter back in.

[xerxes2985]

@Tom-Elliott @george1421 @Wayne-Workman @Scott-Adams

First, I can assure you its a Surface Pro 3. Unfortunately, its the only one I have at the moment so I cannot verify whether multiple SP3 share the same vendor class. (although I am guessing they may)

PXEClient:Arch:00007:UNDI:003016

The other question in regards to changing to snponly.efi, it could have been I wasn’t pointing the BC_EFI entry.

Correct entry

pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe7156.efi

Wrong architecture entry

pxe-service=X86-64_EFI, "Boot Surface UEFI" snponly.efi

Tom, to answer your question, yes I believe you can mark this as solved.

Thanks for all your help.

[george1421]

@xerxes2985 just for reference I’ve started documenting this solution here: https://forums.fogproject.org/topic/8971/pxe-booting-surface-pro-3-to-fog-menu