X1 AIO Desktop - i7 vPro network issue with Intel I219-LM [was: Make new bzImage...]
-
@mandrade On the picture I see that it seems to pop back to the iPXE shell after timing out in the bzImage. Does it hang there or are you able to type in commands? Please run the two iPXE commands
ifstatandnstatto see more information about the state of the network (please take a picture). As well runkernel http://x.x.x.142/fog/service/ipxe/bzImage(use your FOG server IP instead of x.x.x) to see if it is able to load the linux kernel via HTTP.At this stage you have the same two options. Either generate a debugging enabled iPXE binary (see my message below) or you take another packet dump with
tcpdumpand I can have a look! -
@Sebastian-Roth said in Make new bzImage...:
ither generate a debugging enabled iPXE binar
I am able to type commands I type ‘S’ to be taken to the iPXE shell. So I ran ifstat, nstat and also tried to load the kernel. This was the result:
-
@mandrade if undionly.kkpxe works why not just use it? Those systems that work on undionly.kpxe shouldn’t have any issues using undionly.kkpxe and the systems that are currently hanging should work as well.
-
I meant the undionly.kkpxe boots past the ipxe boot screens and into the menus where I can inventory etc. The problem then comes when I make select a menu item like inventory for instance. The result you can see in the image below. I cannot inventory or take an image of this host using either undionly.kpxe or undionly.kkpxe only that the undionly.kkpxe gets further in the process.
-
@mandrade Thanks for the new screenshot. I guess I need another tcpdump capture of exactly this! Can you to another one (same command as mentioned before) and send it to me?
-
Hi, I had already sent a second TCPDUMP to the supplied e-mail. Let me know if you didn’t get it I’ll re-send if need be.
-
@mandrade Based on what I see of the image as found in the reply link It appears the place where it’s trying to download the file is unreachable. Maybe this is due to firewall? The IP address looks correct, but what’s the IP address of the system? Maybe a DHCP command is needed?
-
Thanks for the response Tom. Other workstations work fine, I am able to image them without issue. I did mention earlier that this setup is slightly different from the others in that this laptop doesn’t have an onboard NIC. It uses a OneLink+ mini dock. The thing is I can see it gets an IP from the DHCP server before it starts to the boot process. Somewhere along the line it loses it’s config somehow and then Fog server is no longer reachable.
-
@mandrade The boot process is a bit strange.
Most likely where you’re seeing the issue is one of a couple potential pitfalls. The biggest one, I believe, is that the tftp files you’re using appear to be from a newer (developmental) version of fog. As I understand this is a debug generated set of files, I suppose this isn’t the underlying issue, rather a symptom of something else.
The boot process, in simple terms, is not as simple as the initial DHCP. The first DHCP is for PXE to grab information from. Then it hands the system off to the bootfile, in your case undionly.{k,kk}pxe. When it is in undonly side, it needs to reestablish the DHCP protocol. Do you see the system getting an IP from there? Normally it would reboot, but if it’s just skipping and trying to boot, maybe the bootfile is doing something differently as well? Issues that could be happening, I suppose, are STP (Spanning Tree Protocol), firewall blocking this series of data, system is on a vlan that can’t reach the fog server to download the http data, or possibly (unlikely) all of the above.
-
I am indeed using a trunked version of FOG. There is no firewall, VLAN separation between the host and FOG. It does get an IP otherwise I would not be able to get to the menu to select an option am I right?
When I select inventory from the menu list it starts to attempt to load the bzImage but fails with connection timed out. All just very strange! I then run the same thing only this time on another host that has an onboard NIC and BOOM it works fine. So my take is that it’s something to do with the mini DOCK. Perhaps drivers? I dunno pure speculation from my part.
-
@mandrade Totally understand, just trying to clarify too. Yes, if it’s getting to the menu it should be fine. What if you change the boot file (undionly) to ipxe.pxe?
-
This thread has gotten pretty long. Have you tried all the things Sebastian posted? Can we summarize where things are?
-
this is what happens if I boot from ipxe.pxe:
It just sits there and eventually reboots
-
Yep tried all the things Sebastian has posted. I was requested to send new tcpdump which I sent to the previously supplied e-mail address.
At this stage I am able to image all my workstations with exception of my Lenovo Thinkpad x1 Carbon machines which connect to the network via a OneLink+ mini docking station as they do not have an onboard NIC.
-
@mandrade You’ve tried intel.pxe?
-
DHCP fails and I’m requested to pres ‘S’ to exit to iPXE shell. Probably worth the mention the machine is seeing the interface as a Realteck RTL8153 USB Ethernet Controller (xHCI) v2.00
USB, would FOG handle USB NIC’s differently perhaps?
-
@mandrade the picture appears to show Intel though. If you use realtek.pxe then?
-
Well derp I see the rtl now…
-
same result as when I run Intel.pxe
-
@mandrade said in Make new bzImage...:
would FOG handle USB NIC’s differently perhaps?
Yes,
in the host’s kernel arguments, you would puthas_usb_nic=1
