X1 AIO Desktop - i7 vPro network issue with Intel I219-LM [was: Make new bzImage...]
-
Right but in this case I would have to capture the Host manualy first right? Because, I cannot inventory the computer.
-
@mandrade You could try to register it manually with just a name and MAC.
Also - not sure how possible this might be but you may try @george1421 's USB tutorial.
He wrote a tutorial that was put in the wiki, it outlines how to create a bootable flash drive with FOS on it, that will allow you to image. I’m not sure how you’d incorporate it into the Lenovo Thinkpad x1 Carbon, perhaps a MicroSD card, perhaps a USB Hub…
Basically, this process removes iPXE and PXE from the equation totally. You still use the FOG server, but you’re booting from removable media.
Read through it here:
https://wiki.fogproject.org/wiki/index.php?title=USB_Bootable_Media -
So no dice either way. Tried manually registering the machine and also booting from the bootable USB following the wiki how to https://wiki.fogproject.org/wiki/index.php?title=USB_Bootable_Media. If I boot from the usb it just returns back to the boot menu. If I add the has_usb_nic=1 parameter it boots through to start imaging but hangs at loading the bzImage.
I tried another laptop different hardware of course, one that has an onboard NIC. This worked no problems booted straight and created images seamlessly. So more and more I think the problem here is how FOG handles the Onelink+ mini doc.
-
So I found out that the OneLink+ mini dock required a Firmware update. I now get straight through to the boot menu but when I try an inventory it’goes to the bzImage and hangs at 0%.
I have take another dump and forwarded it to Sabastian hopefully now we will see what’s causing the problem.
-
@mandrade In the mean time, if you have custom menu entries it might be worth trying to load for example an ISO and see if that gets any further.
I’ve had a few devices that wouldn’t get far with the downloading of files in PXE, not sure if (and how) I resolved that, though.
Just for clarity sake as well, which binary are you currently using?
Seeing as the NIC is Realtek, it might be worth testing with Realtek.kpxe if you aren’t already.
edit: Also, seeing as it’s a USB NIC, it might be worth checking out the USB settings in BIOS, particularily those related to XHCI handoff and see if that helps any.
-
@mandrade well then it seems simple to me what needs done next. Order a few different adapters for the device. There are some known good models on the foruforums and wiki. I’d order three or four different models and brands. When you find one that works, order as many as you need.
-
@mandrade said:
Yep tried all the things Sebastian has posted.
I don’t think you have…
Would you be able to build/download a iPXE binary as described in https://wiki.fogproject.org/wiki/index.php/IPXE#rom-o-matic.eu. Right at the end you want to add http,httpcore,httpconn into the “Enable Debug” field. Please take a picture or video of what you see on screen then.
Maybe try connecting a dump mini switch between the client and your network just to make sure it’s not some kind of stupid ethernet energy saving foo magic causing this.
-
In the new PCAP file you sent me I see a similar thing happing as with the boot.php. Client sends ACK for the first 2897 bytes and then is silent. Totally weird! This time there is no chunked transfer.
-
I have tried the rom-omatic.eu guide to create a USB stick. When it boots it fails with "“could not connect to net0: input/output error”
I
-
@mandrade What if you build a simple
undionly.kkpxewith debug enabled http code and do normal PXE boot? Just move the original unidonly.kkpxe on your FOG/TFTP server out of the way and put that new binary in place… -
I’ve been messing around with the BIOS settings etc. I’ve managed to get the machine to get here:
-
@mandrade said:
I’ve been messing around with the BIOS settings
You got to be kidding?!? Possibly this was some kind of weird secruity chip issue again? Please can you reproduce which BIOS setting change did the trick?
About the DHCP error you see now: Do you have a onboard NIC in that machine or is it just the dock thingy? If it’s just that dock NIC-wise then it seems like the kernel actually does detect it as
eth0. Please try using a dumb mini switch to connect between this client and your network. Possibly this might help you. -
@mandrade I would advise trying a different USB NIC, it seems like this one isn’t working properly given that it cannot read the device descriptor properly.
Unless… is this being plugged into a USB3 port? If so, try a USB2 port.
-
@Quazz ,
That’s the thing, it’s a Onelink+ mini dock that I’m connecting with.
The there is also an onboard adaptor I assume is for the USB dongle.
-
@mandrade said:
The there is also an onboard adaptor I assume is for the USB dongle.
I am not sure if I understand what you are trying to tell us. I was asking if there is some kind of “onboard” NIC within the device that might possibly be detected as eth0. While on the other hand the
device descriptor errorsounds a bit like it finds the USB NIC but fails to talk to it.Have you ever tried booting any kind of live linux system (via USB or CDROM) on that machine?
PS: I am changing the title of this post now as I keep forgetting what this is about anyway…
-
I have thrown in the towel for now, seeing as there are only three laptops at this stage it should be ok.
So the full story is, there a two interfaces detected. An internal NIC which can be enabled/disabled by the BIOS(extends to USB dongle) and a second interface on the mini dock(The Realtek 8135 that was Mentioned).
The error device descriptor error comes up when the onboard NIC is enabled. As there is no USB dongle with an ethernet cable present we get device descriptor error. At least that’s my theory! Now, if I disable the onboard, and boot directly from the mini doc, it hangs intermittently. Sometimes on the bzImage and sometimes on the Init.xz. Believe it or not sometimes it goes all the way through but then eth0 was not detected.
Unfortunately these machines did not ship with the USB dongle. So I cannot test if that would work. I have also tried booting using a USB bootable drive but that also fails. I followed this document:
https://wiki.fogproject.org/wiki/index.php?title=USB_Bootable_Media
-
Could also be a driver issue. The PXE boot off the mini dock seems to be a known problem:
The above forum is about a Lenovo Yoga and SCCM but the mini dock is the same. Same realtek driver. The Unix/Linux drivers availabled here:
-
@mandrade said:
Now, if I disable the onboard, and boot directly from the mini doc, it hangs intermittently. Sometimes on the bzImage and sometimes on the Init.xz. Believe it or not sometimes it goes all the way through but then eth0 was not detected.
To me this definitely seems like an issue related to crappy hardware. Possibly the iPXE and kernel devs can work around this in their driver code but maybe not.
Could also be a driver issue. The PXE boot off the mini dock seems to be a known problem
Great find! Sure we could replace the official linux kernel driver r8152 with that one from the realtek website but you’d still see the hangs on iPXE trying to load the kernel most times. Although the iPXE devs have helped us a lot of times and added patches I kind of doubt that you can get them to add the realtek driver code to their project.
Have you tried my suggestion on using a dumb mini switch to connect between this client and your network yet? Possibly this might help.
-
I just tried your suggestion of using a mini dumb switch. This has not made any difference unfortunately.
-
@mandrade Sad to hear that you couldn’t make it work this way either. I think the only suggestion I am left with is try build an iPXE binary and “Enable Debug”
http,httpcore,httpconn. Please take a picture or video of what you see on screen then. Possibly we see exactly where it hangs along the way.