Microsoft Surface Pro 4

[Avaryan]

Hello,

I’ll be getting 20+ Microsoft Surface Pro 4’s soon. I’ll likely have one to test with next week. I already know that I’m going to have issues with them, so I’m asking now how to get these to work with FOG?

I’m assuming these are UEFI only… not something I’ve dealt with yet. If UEFI only, I’ll still need to be able to pxe boot non uefi devices.

[Wayne Workman]

@Avaryan Read through these, they are some of the better threads I’ve collected on the topic: https://wiki.fogproject.org/wiki/index.php?title=Surface_Pro

Also, feel like writing a tutorial?

[Avaryan]

@Wayne-Workman said in Microsoft Surface Pro 4:

Also, feel like writing a tutorial?

Maybe after I actually get one of these devices to work with.

[george1421]

@Avaryan (Warning I have no personal experience with Surface Pros).

For the iPXE boot kernel you will want to use the ipxe7156.efi file. You will also surely want to purchase either a dock for the SPs that has an ethernet adapter or purchase a supported usb to ethernet adapter so you can pxe boot these devices. If you go with the stand alone usb to ethernet adapter, you will want to pick up a powered usb3 hub. At one time there was an issue with the keyboard on the SP working with the linux kernel. I know the linux guys were working on a solution for that, but I don’t know if they where able to work it out.

[x23piracy]

I already imaged Surface 4 Pro, i’ve used the port replicator to boot them:

Afai remember i used them in legacy mode (don’t had uefi images at that point) but it’s possible that the current firmware does not support legacy anymore but ipxe7156.efi should boot them anyway in uefi mode.

But you can also use the usb nic adapter that was available with surface 3 pro’s:

It also supports pxe boot but could be hard to purchase one.

Do you already have a golden syspreped image? If not i would recommend to finish one of them then sysprep it, image it and deploy to all the others. Beware that you should remove the nic’s mac from all the imaged devices associated with fog’s hosts if you use the same dock or usb nic to image them.

Regards X23

[x23piracy]

Don’t forget to disable “Secure Boot” else the Surface won’t boot the fog kernel because of the missing signature.
https://www.youtube.com/watch?v=E47f7n8N4PA

@george1421 @Wayne-Workman @tom-elliott Is there a way to sign the fog kernel to match what the devices would expect from a secure boot kernel?
http://kroah.com/log/blog/2013/09/02/booting-a-self-signed-linux-kernel/

Let’s say this work i think we have to place our own keys into each device, that would would be the same pain (more pain) as just turning secure boot off. Isn’t there a way to use the embedded keys to sign our kernels?

The more i read about that it sounds complicated…

FYI all Surfaces are UEFI Class 3 devices, so no legacy boot. It was never there.

[Wayne Workman]

@x23piracy said in Microsoft Surface Pro 4:

Is there a way to sign the fog kernel to match what the devices would expect from a secure boot kernel?

Yes, @joe-schmitt has looked into this. We’d pay Microsoft to sign our boot files. This would also mean the frequency of updating our iPXE boot files would slow down to once every few years - because every new set would need signed. Currently, I think @tom-elliott is updating the iPXE boot files every couple weeks.

[x23piracy]

@Wayne-Workman that means current ipxe7156.efi is a signed one?

[george1421]

@x23piracy said in Microsoft Surface Pro 4:

that means current ipxe7156.efi is a signed one?

No it is not, its an older build of the ipxe kernel that is known to boot correctly on the SP’s.

I looked over the link you posted and I can say its possible. All efi ipxe kernels would have to be signed as well as the FOS kernel. This is totally possible to do in an automated manner. (I’m not speaking on behalf of the devs only saying its possible)

The issue (as I see it) is on the workstation side. The workflow (to me seems a but complicated). Somehow you need to get something (already registered) to boot. Then you can add the FOG kpi keys. If you read the instructions you actually have to remove the MS signed keys (!!). Then you can add your self signed keys. The problem here is that these keys are only for FOG supplied boot images. What happens if you want to run windows after that. You’ve unloaded the MS keys and loaded FOG’s keys.

IMO its much easier to just turn off secure boot, deploy the image with FOG and then (if Dell use cckt to) reeanble secure boot.

[Wayne Workman]

@x23piracy No, it’s not. It’s just the only one that works with Surface Pro 4s. We need to find out why, but the developers don’t have any Surface Pro device to test the code commits around that time with. Someone has to step up and send Tom or George or myself a Surface Pro to test with. That’s all we need to get this straightened out - it’s all we need to have real documentation.

[x23piracy]

@Wayne-Workman What about crowdfunding? I would give some dollars for this.

[Wayne Workman]

@x23piracy That could work - it would be for an individual though, not ‘fog’. The money should go to @george1421 or @tom-elliott so they can buy a Surface Pro.

[Avaryan]

I doubt I’d be allowed to send them one of ours, but I could test things here.

[Sebastian Roth]

@Avaryan Well, if you are keen to try out several different iPXE binaries (maybe in dozens)… I am happy to provide those for testing pretty soon.

@Tom-Elliott Am I right that ipxe7156 is compiled using this ipxe git commit? As well, do you know a git commit having the issue and being kind of close to the working one so we don’t have to bisect down from the current version?

[Sebastian Roth]

@Avaryan Please find a test plan in the spreadsheet and binaries here. Start from the bottom of the table. Download 01_ipxe.efi and point your DHCP to that file (I prefer this to renaming the file to not confuse the files while testing several different ones). Schedule an upload task for one of your surface clients and boot it up. With 01_ipxe.efi things should work fine - just to confirm. Then work your way up the list and update the status in column B - ok or hang…

[Tom Elliott]

@Sebastian-Roth The git commit is accurate (7156 was the starter). I’m not sure what’s changed since this was implemented all the way to now. My thoughts were to find the 7156 as “working” and the closest to “broken” and run git bisect from those so we could hopefully determine exactly when it was introduced.

[Avaryan]

@Sebastian-Roth I don’t have access to the DHCP server, so would renaming and uploading the file work? Will keep track of names.

I’m still waiting to get my hands on the surface device.

[Sebastian Roth]

@Avaryan Sure you can run the same tests and just rename the files to ipxe.efi every time. As we have the git commit rev in the binary we’ll always figure out which was which. When iPXE comes up, it says “iPXE 1.0.0+ (xxxxx) – Open Source Network Boot Firmware” where xxxxx is the start of the git commit rev you see in the spreadsheet.

I really hope we can find out what is causing this hang on surface devices…

[Sebastian Roth]

@Tom-Elliott While building all those binaries I was wondering if maybe a change in the iPXE header files (general.h, settings.h, console.h) was - and still is - causing iPXE to hang on those surface devices?! Well see.
Anyhow, I will stop building more binaries for now and wait for the firsts test results. Let’s see if the newly built 7156 actually is working… Looking forward to hear from you @Avaryan

[Sebastian Roth]

@Avaryan Did you get to test some of the binaries yet? I uploaded the full set now.

Would be great if others ( @sarge_212 , @jhuesser, @Psycholiquid, @fry_p, @Scott-Adams, @xerxes2985, @dylan123, @ecicerkofski, @Arsenal101) could also join the testing so we hopefully find what is actually causing this issue and eventually get rid of those extra-7156-ipxe binaries… Find the test plan and binaries here. Please start from the bottom of the table (01_ipxe.efi) and mark rows as you test those. Thanks in advance!

@Tom-Elliott In case none of those binaries work (not even the 7156 one) then I reckon we have an issue with the iPXE header files. For this I have put together another test plan in the subdirectory called ‘svn’ where I put all the iPXE binaries that were compiled around that time - plus the header files (in ‘svn/config’ dir).