Microsoft Surface Pro 4
-
@sebastian-roth I ran a tcpdump with a different device to see what would happen. I tried using one of our HP desktops and it captured all DHCP and TFTP packets properly as you’d expect, with the same UEFI PXE boot over IPV4 settings as the Surface. If you want to see for yourself, I’ll post the PCAP file but otherwise you can take my word for it: it worked just fine as you’d expect and even did a successful deploy and capture.
I’m not sure what Microsoft is doing with this particular NIC on this dock, but I think that somehow it’s blocking DHCP in PXE boot somehow because that’s the only explanation that I can think of with my current knowledge of networking. As you can see from the PCAP file I posted, the device even has an IP address of 10.241.70.172 upon connection to the FOG server - SOMEHOW - but does not get it via DHCP as there are no DHCP packets. As if it were cached or something. I’m so confused as to how this is even functioning.
Furthermore, if I boot into Windows, the wired connection works just fine - so it’s not a defective dock or anything. It works in Windows, just not in PXE. Absolutely bizarre.
PS: I’ll have to purchase a hub because I don’t believe we have one in house. We have a switch, but not a hub.
-
@mwarner said in Microsoft Surface Pro 4:
We have a switch, but not a hub.
A switch that supports port mirroring will work just as good without the spend.
I have that surface book right now with the external dock. You are right its not a usb-c but something microsoft specific. I hope to be able to get it pxe booted later this afternoon to see what I can see.
-
@mwarner Yeah, I’d be happy to take a look at the HP desktop bootup PCAP. Just send me a PM if you don’t want to share this in public.
As you can see from the PCAP file I posted, the device even has an IP address of 10.241.70.172 upon connection to the FOG server - SOMEHOW - but does not get it via DHCP as there are no DHCP packets. As if it were cached or something. I’m so confused as to how this is even functioning.
PXE booting in the case of FOG is not just one single thing. It’s a whole series of protocols and stuff working together to get up that FOS (FOG mini linux OS) in the end. At that stage were you see the error the client got an IP via DHCP twice already. And also communicated with the FOG server. So we do know that your setup is not totally screwed. But for things to fully work each and every piece of the chain needs to play nicely.
So to try and circle what’s causing this I’d suggest you prepare a live Linux CD or USB key to boot from. See if you can that up. Not through PXE, just normal bootup from CD/DVD/USB key. Then try to setup a network connection.
@george1421 Great to hear you got such a thingy at hand too. Looking forward to hear what you find. If you get stuck at the same stage try Live Linux to see if that can bring up that NIC properly.
-
OK first let me say, I’m too frick’n old to try to work with these things in console mode. That text is damn small, about 4pt in size.
Short form: It werks as advertised. I can pxe boot and register the surface book via the external dock thingy. You must use kernel 4.11.6, the stock kernel that comes with FOG 1.4.4 4.11.0 does not werk. You can tell if you have the older kernel (at least with the surface books is that they onboard keyboard does not function correctly.
At the moment I think the dock’s model number is PF3-00005
The longer form will have to wait until tonight. I have color pictures and logs to post, but no time at the moment.
-
@sebastian-roth I got you two PCAP files on a different VLAN with an IP helper on it that captured more information from both the HP and the Surface. Here is a link to a Google Drive folder containing those files. I’ll try to leave them up for future reference to this article.
-
@mwarner I am sorry to say this but the PCAPs don’t show the DHCP answer packets (offer and ack). So it’s missing very essential information.
Have you looked into booting a live Linux OS on the Surface just to see if that can properly bring up the network interface and retrieve an IP via DHCP - see my last post.
-
@sebastian-roth When I was testing earlier today, I usb booted FOS to skip th pxe boot stuff. I can say right from the start, iPXE did work correctly, but when the linux (FOS) kernel started it would not pick up an IP address, and the on board keyboard would not respond. I plugged in a usb keyboard and I was able to navigate, but the network would not come up.
I played around a bit with the dock and disconnecting it and reconnecting it. The FOS kernel saw those changes. It reported the nic in the dock as a Real tech nic. I can’t remember why I thought to update the kernel other than I was using a USB FOS stick created last may. Once I booted on USB FOS with the 4.11.6 kernel the network ms adapter picked up an ip address. Once that was done I was able to register the target computer.
@mwarner on your fog server linux console, will you navigate to this path:
/var/www/html/fog/service/ipxe
and once in there key infiles bzImage
and post back the version number reported? -
@george1421 The command reported back this:
bzImage: Linux kernel x86 boot executable bzImage, version 4.13.4 (root@debian64) #2 SMP Wed Oct 18 15:26:04 EDT 2017, RO-rootFS, swap_dev 0x7, Normal VGA
How can I upgrade to 4.11.6?
-
@mwarner I got them from the following links.
wget https://fogproject.org/inits/init.xz wget https://fogproject.org/inits/init_32.xz wget https://fogproject.org/kernels/bzImage wget https://fogproject.org/kernels/bzImage32
Just make sure you save your current files before overwriting them
-
@george1421 Good news and bad news!
I was able to get the DHCP working using the new inits/kernels. I was able to register the host and run the compatibility settings option just fine.
Unfortunately, I was not able to run a capture task. Below is an image of the result.
I have no clue what could be going on, should I run another tcpdump?
I should also add that there is a substantially long pause between where it says “OK” and where the error starts - I’d say maybe 30-60 seconds.
-
@mwarner One question, are you booting via the USB stick? If so, you MUST schedule a task on the FOG server before you attempt to boot with usb stick. While the error is a bit cryptic, that is the typically the error.
If you ARE booting via the usb stick, why? I was able to pxe boot the surface book and capture without issue.
-
@george1421 I am booting via USB stick. I tried PXE and it didn’t seem to work - same errors as before. I created the task before booting.
-
@mwarner And so it works now?
The error message basically translates to I tried to deploy an image but there wasn’t anything for me to do (i.e. request type: null [nothing to do]). Same error as before as in your are still deploying the old bzImage from your fog server?
[Edit] Oh I see you updated to fog 1.5.0RC10 a few posts ago. So you should have the latest kernel on your fog server. There may be an issue with the usb boot and fog 1.5.0. I have to look at it, but the developers change (in 1.5.0 to add the ability to deal with http and https installs of fog). That maybe why its returning an invalid null type.
-
Looking at the code in the grub.cfg file, lets try to update it as such.
change
<snip> ramdisk_size=127000 keymap= web=$myfogip/fog/ boottype=usb
to
<snip>ramdisk_size=127000 keymap= web=http://$myfogip/fog/ boottype=usb
Note the http:// inserted just before $myfogip. You need to do that for every row that has
web=$myfogip/fog/
in it. -
@george1421 Yes, the DHCP works now when I use the USB stick. I’d still prefer to go without it, but it can suffice for now.
What do you recommend the next step should be for me? Should I wait for the next stable version of FOG to be released? In the meantime, should I go back to bzImage 4.13.4?
-
@george1421 where should this grub.cfg file be located?
-
@mwarner Grub.cfg is on the usb stick. Its in the boot/grub/grub.cfg path.
-
@george1421 Unfortunately that didn’t seem to fix anything. Should I revert my kernel back to 4.13.4?
-
@mwarner You can or leave it at 4.13.6 since that has proven to work with the surface devices. When 1.5.0 stable is eventually released it will contain that or a later kernel anyway.
I guess I need to look into why 1.5.0RC10 is giving us an issue with USB booting.