UEFI Surface Pro 3 + Fog 1.2.0 on Ubuntu 14.02
-
First time posting technical help and thank you to FOG, as I have been using it for years now and all you guys have always helped me simy by reading other posts.
Problem:
Surface Pro 3’s I cannot get it to boot into Fog pxe environment. I hate these devices, but company needs to deploy them on large scale, so I want to support that business decision.I am running Cisco router with “undionly.kpxe” as the file to detect.
I have a MS USB to Ethernet adaptor. Disabled secure boot, red screen and it attempts to boot off pxe (seems like uefi) but ofcourse, does not boot or want to connect with fog server.
I have created my own rom from rom o matic, using a USB hub, Ethernet adaptor and desperate USB key with my next server ip and undionly.kpxe as boot file within the rom, and a little more success there. Issue is I can see it connecting (trying too) to Fog server, message reads:
“iPXE Initialising Devices … Ok
Configuring (net0 and then my MAC address)”
It just hangs there and after a few seconds co to yes to the Uefi pxe IPv4 and IPv6I am thinking berween my server and device, something is not handshaking. I just don’t know what and I need some guidance what to do.
I have been using it for years now on at least 30 different devices, always found workarounds with Tftp kernels from Fog Management Console to help. But this uefi is now becoming more and more mainstream and I would like to be able to boot either uefi/legacy
Thanks.
-
Surface Pros are UEFI devices as you’ve said in your post, which means that
undionly.kpxewill never work for this device because it’s a BIOS/Legacy boot file.The surface pro will need
ipxe.efibut the problem is many of your devices still needundionly.kpxeand it’s silly to swap them back and forth. So, whatever is running DHCP in your environment (I guess the Cisco router) needs to be configured to identify and support multiple Vendor Class Identifiers. We have an article written just for this, right here: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-ExistenceNext, I’d strongly advise you to upgrade to FOG Trunk (article: https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk). While it’s possible to modify 1.2.0 to make it work with the Surface and other devices, I would advise against it. Trunk supports newer device types with newer persistent storage out-of-the-box, and FOG Trunk is very stable right now, in my opinion it’s almost release ready.
Also - if at all possible - I’d like to help with the Cisco DHCP so that I can document the steps in our WiKi, or at the very least, you give us your documentation when you’re done. Good, clear, concise, and accurate Documentation is one of the best ways to give back.
-
Hi Wayne,
Thanks for that. But I am a little confused, so please forgive me.
-
You said “Vendor Class Identifiers. We have an article written just for this” but there is nothing in there about Cisco configuration for multiple vendor class identifiers.
-
“I’d strongly advise you to upgrade to FOG Trunk” but then later “I would advise against it.”. I am not sure if I should or shouldn’t.
From what I can gather, Windows server DHCP is the most flexible way, and seems like you can inject multiple boot files (undi / ipxe / snponly etc). Perhaps I should move from Cisco DHCP to Server 2012, as its easier to manage.
Question, if I go to Windows Server DHCP, am I correct in assuming it allow multiple boot files automatically depending on device.
So if UEFI device is trying to boot, it will boot the ipxe and if we have older devices, it will boot same old undionly file?I will go and do some research on Cisco multiple Vendor Class Identifiers and see if its possible, and will post back if successful and with steps.
-
-
@spetzmax He means it’s possible to modify 1.2.0 to work with the surface and other devices, but modifying 1.2.0 is “advised against”. I say you should update to trunk, if only to get on the stuff I’m working on and can provide a bit more help with.
-
The idea with the vendor class is that when the client boots, it sends out what type if device it is to the proxy server. It will send if it is a bios, efi32 or efi64. The dhcp server will look at this vendor class and send back the appropriate boot file. This is the ideal way to do this. The most common dhcp serves are microsoft 2012 (must be 2012 to get this function), or linux dhcp server. Your cisco may have it so you might want to check. Right now we are not aware of anyone who is using dhcp and vendor classes on a cisco router so there is no wiki available for you. You are swimming in uncharted waters right now. The other option is to define a specific boot file on a per device/mac address. This is not very scalable, but if you only have one or two devices it is manageable until you can get a better solution in place.
I would recommend you get a fix for this sooner rather than later since more and more devices are coming out as uefi only.
-
@spetzmax From what I can see here it seams like Cisco is kind of able to detect vendor class identifier: https://damn.technology/configure-cisco-ios-dhcp-to-use-vendor-class-ids
Unfortunately I couldn’t find anyone using “ip dhcp pool … class” definition to send different options to the clients. Only IPs from different ranges. That’s not what you want.
From what I found out so far it seams like it would be way easier to use a linux DHCP server to make this work for you. Would it be possible in your environment to move the DHCP serving from your router to your FOG server for example?
-
@spetzmax Did you get your cisco router configured properly or did you end up using a different DHCP server?
-
We are requesting that all community members who have Surface Pros to please do a packet capture, to capture the DHCP conversation the client sends out at boot time via the ethernet dock, and upload the capture here. The intent is to gather more information about the Surface Pro, so fog can better support network booting it.
Thanks,
Wayne
