Surface Pro 3 - ipxe issues
Ok, so I have spent the last two hours perusing through the old thread, and cannot come up with a working solution. Maybe I am missing something.
Here’s my setup
I have a VM running Ubuntu Server 16.0.4 LTS. Fog v 1.3.0 is installed using dnsmasq, as I cannot utilize the “work” DHCP server.
I can PXE through VMware, register/capture/deploy images. I can PXE on a laptop and capture an image.
When I try to PXE boot through the Surface Pro 3 (native UEFI pxe boot), using the Microsoft USB-Ethernet Gigabit adapter, the Surface recognizes two of my architecture entries (X86-64, ipxe.efi and snp.efi) from itsp.conf in the PXE boot menu. But neither one will pull the Fog Menu to allow me to register/capture/deploy etc.
@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
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)
The other question in regards to changing to snponly.efi, it could have been I wasn’t pointing the BC_EFI 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 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.
@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.
@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.
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.
So now that you have a working system, is it safe to solve this thread?
@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
@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.
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:
@xerxes2985 is it possible it’s looping back because it’s looking for snponly.efi.0?
@xerxes2985 You have the proper setup now. Adding filters (if you need them) is just a short walk from there. There is two ways you can go with the config file, easy and a little harder. But the little harder gives you many more options.
The wiki page you referenced is based on my working document here: https://forums.fogproject.org/topic/8726/advanced-dnsmasq-techniques
which goes into the details a bit more.
I’ve modified my itsp.conf to the following based upon ProxyDHCP_with_dnsmasq:Adding (a bit more complex) UEFI support to the basic script
port=0 log-dhcp tftp-root=/tftpboot dhcp-no-override dhcp-vendorclass=BIOS,PXEClient:Arch:00000 dhcp-vendorclass=UEFI32,PXEClient:Arch:00006 dhcp-vendorclass=UEFI,PXEClient:Arch:00007 dhcp-vendorclass=UEFI64,PXEClient:Arch:00009 dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,x.x.x.x dhcp-boot=net:UEFI,ipxe7156.efi,,x.x.x.x dhcp-boot=net:UEFI64,ipxe.efi,,x.x.x.x dhcp-boot=undionly.kpxe,,x.x.x.x pxe-prompt="Booting FOG Client", 20 dhcp-range=x.x.x.x,proxy
The key to getting the Surface Pro 3 to PXE boot into the FOG Menu, and successfully start a Full Registration was modifying the following values.
I am currently 12% of the way through capturing an image, although my VM will probably fill up.
I had a quick IM session with the OP. He was able to get the surface pro to boot using the ipxe7156.efi file. He went the bit longer way the wiki defined to get to the right answer. But this route would have worked too. (the longer way is the proper way if you need to add filters some time in the future).
<edit> the OP IM’d me and said that this route did not work as expected so he went the longer route. Do no follow this section since it is now suspect.
In his posted ltsp.conf file, if he would have replaced
pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi
pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe7156.efi
it would have worked equally as well.
But this way unfortunate all Arch 7 type devices would get the same ipxe boot file. With filters you can tailor the boot file based on the specific booting client type (assuming that the vendor set the uuid field correctly)
I’m IM’ing with you but its pretty lonely when you don’t respond.
Here is the relevant information from the pcap file. Its packet #7.
We can see that this device has a unique UUID which is cool we can use that if we want to create a custom dnsmasq filter.
We also can see that the system arch is type 7 EFI BC. That info will be used in the ltsp.conf file. According to your posted config file dnsmasq should send ipxe.efi for the type BC_EFI.
Now that I figured out how to take it out of my Ubuntu server, here is the file.
here’s a wireshark capture I did of any traffic going into FOG
In my environment, I use both Surface Pro 3s and Surface Pro 4s.
I use snponly.efi and can image my Surfaces.
Could you document your entire setup for the surface pros only the PXE booting and FOG parts. We need to know dhcp settings and network adapter used, and if there is any relevancy to bios version or setting you did to make this work. I think you hold the key to getting snponly.efi or even ipxe.efi working for these guys.
@george1421 Completely agree. I’ve been meaning to collect all of our information and put it in one spot. I’ll start on it tonight at least, and at least get all the links together.