Posts made by mwarner

@george1421 Unfortunately that didn’t seem to fix anything. Should I revert my kernel back to 4.13.4?

@george1421 where should this grub.cfg file be located?

@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 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.

@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.

@sebastian-roth Unfortunately it has been lower on my priority list right now, we are undergoing a lot of changes as a business right now. I’ll update ASAP.

@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?

@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.

@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.

@george1421 Awesome! I’ll be interested to see what you can pull off and if it will help with our case. Unfortunately our docks aren’t USB-C though. We have the Surface Pro 4’s (2-in-1 device) that have a proprietary plug for the dock connection. It’s definitely not USB. Probably why USB NIC option isn’t working.

@avaryan said in Microsoft Surface Pro 4:

Are you willing to purchase a different USB NIC?

Unfortunately not, we have already purchased the full blown docks for our supply of surface pro 4s in a bundle from CDW.

@sebastian-roth Here is the link to a .pcap file of the surface in question trying to connect. The surface itself loads the FOG menu properly and successfully, as shown by the .pcap, but when I selected the “Perform Full Host Registration” option it seems to recognize that there’s an error with the ethernet connection. Perhaps you could provide some more insight?

@sebastian-roth Also I’m now testing with v1.5.0-RC-10 and ipxe.efi.

@sebastian-roth I tried using a Netgear GS308 per your suggestion of using a mini switch and it did not work (with or without has_usb_nic=1)

@Sebastian-Roth Yes, I’ve tried to unplug and replug the dock connector in multiple times and every time it ends up with the same failure to get a DHCP address.

Hello,

I’ve been searching on the forms for hours and none of the previous threads on this topic have helped so far. I’m having the “typical” inability to find an IP address via DHCP issue. It tries to bring the link up on eth0, but there is no eth0 device since the NIC is on the external Microsoft Surface Dock. I booted into a Linux live disk to see what the device name is given by default on a unix device and it’s set to enxc49dede708d4, which is an insanely long name for a NIC. Not sure if this helps at all, but thought I’d add it anyways.

I’ve only had success (with all devices on my network) with ipxe7156.efi - intel7156.efi does not work. UEFI PXE is working fine, but once I try to do a registration with the Surface Pro 4 it hangs on finding an IP address.

I’ve also tried the “has_usb_nic=1” solution but it does not help - I’m using the dock and not a usb NIC so it has it’s own proprietary connection interface that is not a USB.

I’m running on FOG 1.4.4 but am soon upgrading to 1.5.0-RC9.

Anyone have any ideas?

@sebastian-roth I’ll try upgrading to 1.5 - I’m familiar with git and the upgrade process. I’ll post my findings after the upgrade is complete.

@sebastian-roth No worries, I appreciate the effort. It’s not a top priority on my list and if it can’t be done then that’s fine, but I’d like to get to the bottom of it so I can get back to my boss about the status of the project.

@sebastian-roth

label: gpt
label-id: F648D791-9536-40F2-A0D3-3A25F0227609
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 1954210086

/dev/sda1 : start=          40, size=      409600, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=FCC1F955-3052-49AB-AE2C-ED013B75ADE9, name="EFI System Partition"
/dev/sda2 : start=      409640, size=  1952530904, type=48465300-0000-11AA-AA11-00306543ECAC, uuid=A0816DEE-EEEA-40CD-BE23-14270C02A1D9, name="Macintosh HD"
/dev/sda3 : start=  1952940544, size=     1269536, type=426F6F74-0000-11AA-AA11-00306543ECAC, uuid=1B0326DE-5FF2-40EE-B8DA-44645187605A, name="Recovery HD", attrs="GUID:49"

@Wayne-Workman @Sebastian-Roth All nodes are currently running v1.4.4 which is the latest stable version as far as I am aware.

Here is a screen cap of my ls -la output.

@Sebastian-Roth Thanks for the heads up - I’ll still try to image it anyways but if it doesn’t work now I’ll know to stop trying.