UEFI-PXE-Boot (Asus t100 Tablet)
@JJ-Fullmer Thank you for the reply! Even after it’s been so long haha. I’ve been meaning to come back to this but it isn’t necessary for me until a break when it’s time to maintenance these computers. I will definitely try this when the opportunity arises. I did try to PXE boot one the other day and noticed that it got further than it had during the time this post was made. It still did not work and I didn’t pursue it any further, but with your guide it seems hopeful! Thank you again!
Thank you good sir. I did a quick quote of the post and added it to the tutorial section to go back later and write it nicer
I added a Too long; Didn’t Read at the top for a quick overview of what the guide is saying.
I’m sure there are very many alternatives and possibilities. I know of a few, but the overall idea is the same. I would love to hear any thoughts you have. Replied in the other post to let this one die of course.
@JJ-Fullmer I really want to understand your post (but I traveling right now). I would recommend that you repost this as tutorial in the tutorial section. I would like for this information to not be mixed into a thread. Just skimming this I think there is an alternate way to do part. But this is a brilliant guide.
There is a way to image these with fog.
Supposedly you should be able to just enable the network stack in bios and then if it’s a ethernet adapter that’s recognized you can set it as a boot option or select it by hitting esc to bring up the boot menu.
However since that didn’t work for me, I found a different method.
It’s a little bit abstract, but not too hard, I promise, give it a chance.
What I used (I did 64 bit efi, substitute 32 bit versions of .efi files if you wanted to do 32 bit)
- A usb hub, any hub with 3 or more ports should do. I was using a powered usb 3 4 port hub.
- I used the startech USB210000S2 Usb ethernet adapter. It has the SMC LAN 7500 chipset, which is the important part
- 2 usb drives, no substantial size needed. (you may get away with one, but I used 2)
- On the first FAT32 formatted usb drive you just need a couple files in the root of the drive
- the efi driver for the usb (found at this link http://ww1.microchip.com/downloads/en//softwarelibrary/obj-lan95xx-uefi/lan95xx_7500_uefi_driver_0.5.zip, also attached 0_1479851633433_SmscUsbNetDriver.efi , also credit where credit is due, I discovered this file via this blog post http://www.johnwillis.com/2014/03/pxe-booting-using-usb-to-ethernet-dongle.html) (also I renamed this to usb.efi for simplicity later)
- ipxe.efi from your /tftpboot folder on your fog server, copy it off with your favorite ftp/scp client. (or just download the latest one straight from the fog project github https://github.com/FOGProject/fogproject/raw/dev-branch/packages/tftp/ipxe.efi)
- You can also put these files on the root of the C drive
- On the second flash drive
- It makes a ~6MB partition that I’m not sure can be extended to fit the other files
Now plug the usb ethernet adapter, and the flash drives into the usb hub and plug the usb hub into the asus t100 usb port (well technically I have a T100H, but this method also worked on a Fusion5 chinese tablet, RCA Cambio tablet, and the atom and core M versions of the intel compute stick).
Now boot to the bios to make sure the secure boot setting is off and the network stack is enabled. It will probably work regardless of the network stack setting, but better safe than sorry. (Note: I always seem to have to hold shift and hit restart from windows to force it to boot to uefi firmware)
Save changes and exit and start tapping esc
tapping esc on boot should bring up a boot menu. Select the refind EFI usb drive.
On the ReFInd gui boot screen select one of the efi shell options.
at the efi shell find which fs (file system) your efi files are on (the ones put on either the second flash drive or the C drive) by running these commands
keep incrementing fs# (fs0: fs1: fs3: etc.) until you see your ipxe.efi and usb driver files.
When you find them run these two commands to start the pxe boot
#replace usb.efi with whatever you named the driver file load usb.efi ipxe.efi
It should start at ipxe initializing devices
If you use the 32bit versions, don’t forget to set your kernel and init in the fog gui for that host.
Another caveat to this method is you have to remember to change the mac address from the usb ethernet adapter to the wifi mac of the device in the fog gui.
Sure it’s not as smooth a system as wake on lan to network boot, but as daunting as it looks it all takes less than a minute to get it booted to pxe.
If you have problems with this, you may try setting a static ip address for your adapter in dhcp and make sure it’s pointed to fog. I have the uefi/bios coexistence setup with the policies found in the fog wiki in my windows dhcp and it works perfect.
If you read all that and think, that’s too much work for so many devices. Well than get a few of these usb setups. I used this method on about 30 intel compute sticks (didn’t require the refind usb, they have a built in efi shell) and it didn’t take all that long.
In theory, I imagine it’s possible to image these with wifi, but that’s a challenge for another day.
@K-Hays You are welcome to get back to this anytime. I am definitely interested to see if we can figure this out. I’m sure we will at some point…
@Sebastian-Roth Hey, since summer hit we’ve been very busy with setting up lots of new things so i haven’t had time to check the forums. Also we are just going forward with regular maintenance on these for now, but I’d like to leave this topic open because it is something that we will need to figure out. If i have an off day ill test this and get back to you, but at the moment it will be on the back burner. Thanks for all of the help so far!
@K-Hays Sorry for the delay. Most days I just don’t have enough time to think about those complex (and interesting) problems as much as I’d like to. Today I found some more time to re-read and think about it.
Also if we use a regular nic on a purely uefi laptop, we get the pxe-18 error, which is server timeout,which is what we get with the tables when they are booting from the adapter. Don’t know if this is just a coincidence or not im not sure.
This and the mentioned subnets plus ip-helper stuff make me think that it’s not the adapters but a network configuration issue. The world best tool to find issues in your network is wireshark/tcpdump as you can really see what’s on the wire. Anything else is just guess work - which I prefer not to do because I mostly go wrong.
In this case I guess the packet dump wouldn’t hurt but probably won’t shed much light on this as the client simply never gets an answer from the DHCP. But as your normal clients seem to get an IP via DHCP (even in the 10.40.0.x subnet I suppose?!) I am wondering why don’t a PXE booting client is getting the information? My guess is the DHCP relay is not properly forwarding all the PXE information in the DHCP packets. I think you need to tell us more about the DHCP relay software you are using. Is it cisco ip-helpers or ISC-DHCP-RELAY or …? Please if possible post the configuration here (or send me a private message if you feel this information is too sensitive for the public).
@Sebastian-Roth So i tested both of them on a regular desktop and i got the “Media Test Failure, Check Cable” error. It seems to me that it’s trying to boot form the regular nic. When booting to the usb it just said no device found or whatever. I dont know if there is a setting to change or whatnot, or if it really is just the adapters. the reason we didnt think it was the adapters was because the first one we got, wouldn’t show up at all on the tablets. It wouldn’t register as a boot device, but the next two we got did. So we figured it was on our side now. Is it just that none of these adapters work properly with pxe? Also if we use a regular nic on a purely uefi laptop, we get the pxe-18 error, which is server timeout,which is what we get with the tables when they are booting from the adapter. Don’t know if this is just a coincidence or not im not sure.
@george1421 yeah, they do.
That’s what I kind of expected. From what I’ve read so far I guess this is not a DHCP issue primarily - but more an issue with the USB NIC adapters. Can you try booting one of you normal PCs using those USB NIC adapters just to proof that they work.
The issue with USB NICs is that the firmware/BIOS needs to have a driver to PXE boot from it. In other words PC/tablet and USB NIC need to “work” together. So the USB NIC not working with one machine does not mean it wouldn’t work with any other. Please try out different things and keep us posted. Possibly as well get another adapter to try out. Check on our list as well… hape we can make this work!
@george1421 yeah, they do.
@K.Hays The feedback I received was its not available yet.
Just because I’ve been dealing with multiple threads in these last few days. Do other computers on the same client subnet boot normally?
@george1421 Any luck on that program?
@K.Hays I understand what you are saying. If there is no dhcp scope assigned to 10.100.x.x. you are back to setting up wireshark on a mirror port.
I know the dev team was working on a utility that would act as a dhcp client so they could capture this info without having to setup a mirrored port and packet scanner. Let me see if they made any progress with this program.
@george1421 All of our servers are static ip based and there is no way to put the client pc on the same subnet as the dhcp because the 10.100 server range is only a static ip range. If that makes sense, i’m trying to explain it as best as possible.
@george1421 We have a Dhcp relay, and a total of 5 different subnets. The dhcp is also running Microsoft server 2008. We may try to bring the client pc and the capture device to the Dhcp on Friday.
@Sebastian-Roth yeah it was a bit buried in the text.
k.hayes posted: Also the dhcp server does not have a 10.40.0.x address. it would be 10.100.0.x
This tells me that the dhcp server is some place else and they must have two or more subnets and to have a single dhcp server they must be using a dhcp-relay / helper service. It was a bunch of reading the tea leaves here, but tha tis how I came up with my conclusion.
I was wondering when Mr. PCAP was going to wake up and join in.
Well… I am sorry but I get paid now for doing same kind of debugging stuff at my new job. Trying to keep up with the forums but it’s not easy!
I think I missed the part about dhcp helpers and subnets. I don’t see different subnets in the packet dump?!? Beside that I think it depends on the relay being used. If I remember correctly we had always broadcasts when using ISC-DHCP-RELAY in our network back at the old working place.
Why do we see so many malformed packets in the dump file. Never seen this before!! The issue with Windows DHCP server is that it does not broadcast the DHCP answers (if I remember correctly).
I was wondering when Mr. PCAP was going to wake up and join in.
If I remember correctly on how a dhcp-relay works, is that on the return trip sending stuff from the dhcp server to the client on another subnet it uses unicast messages and not broadcast (or it uses a directed broadcast which is similar to a unicast).
Why do we see so many malformed packets in the dump file. Never seen this before!! The issue with Windows DHCP server is that it does not broadcast the DHCP answers (if I remember correctly). So we will see the DHCP discovery packets from the client but not the answers.
@K-Hays Would you be able to install wireshark on that DHCP server? Then open it up, start capturing, put
bootp || tftpas display filter and boot up your client. When you see the error stop wireshark. Then export only the packets that are seen by the display filter (there is an option in the export dialog. Other than that there are only more complicated ways of getting the information. One would be to use a hub (instead of a switch) to connect the client to the rest of the network. On every port of that hub you can capture the client’s network traffic using another computer using wireshark again.
@K.Hays The key will be to get the dhcp server, booting client and packet capture device into the same broadcast domain (subnet). To get a clean capture. This will avoid having to mess with switch configuration for port mirroring.
Also for clarity, your dhcp server is a microsoft dhcp server? If its a 2012 dhcp server we have a few more options when dealing with bios and uefi clients. Typically the dhcp server should just hand out dhcp addresses unless you are doing something already for bios and uefi clients. In that case this device is a IA32 device where most computers are x64 which has a different arch ID.