Realtek NIC fails to load undionly.kpxe?



  • The Server:
    FOG 1.4.4 on Ubuntu 16.10 on VMware ESX 5.5
    FOG server is NOT the DHCP server
    FOG is running on the 4.13.4 TomElliott kernel
    bzImage Version: 4.13.4
    bzImage32 Version: 4.11.0

    The Network:
    Spanning-tree turned on for all ports
    DHCP server has option 66 set to FOG server IP, option 67 is undionly.kpxe

    The Laptop (and one of the current banes of my existence):
    ByteSpeed E15K
    InsydeH2O bios version 210
    Realtek RTL8168H NIC

    So I have set this laptop in BIOS to boot from PXE, both using UEFI IPv4 and Legacy, and I cannot load the FOG PXE menu at all. The only picture I could get was from the Legacy PXE boot (the UEFI disappears too fast to read):

    alt text

    I’ve talked to the laptop OEM and they seem to think I need to load the drivers for this laptop onto my FOG server. However, from what I read it sounds like the drivers are built into the kernel, which is why I updated to 4.13.4 which appears to be the latest and greatest. But to no avail…

    I’ve disabled Secure Boot in the BIOS as well but that did not help either.

    I’m a little capable in Linux (enough to setup Ubuntu and update FOG LOL) but not well versed in PXE at all.

    How can I get this laptop to boot into FOG?



  • @cabraln said in Realtek NIC fails to load undionly.kpxe?:

    02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)

    That’s your wired NIC, thank you for providing that. Please look into 802.3az as George requested.



  • @wayne-workman The NIC did work on a live-boot of an Ubuntu 16.10 live CD. Here’s everything I got from running lspci during the live session. The only difference, and I forgot to mention this in my original post, is that my FOG install is running on Ubuntu Server Core, so maybe there’s a driver package that’s included by default in the Desktop version that’s not installed?

    00:00.0 Host bridge: Intel Corporation Device 5904 (rev 02)
    00:02.0 VGA compatible controller: Intel Corporation Device 5916 (rev 02)
    00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)
    00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)
    00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)
    00:17.0 SATA controller: Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode] (rev 21)
    00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1)
    00:1c.5 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #6 (rev f1)
    00:1f.0 ISA bridge: Intel Corporation Device 9d58 (rev 21)
    00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
    00:1f.3 Audio device: Intel Corporation Device 9d71 (rev 21)
    00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
    01:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
    02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)


  • Moderator

    @cabraln OK so it does pick up an ip address after the 27 second stp delay before forwarding. So I would focus on spanning tree first. Since you have a realtek nic also look into green ethernet settings (802.3az) on that switch we have seen the green ethernet configurations some times case realtek nics to act strange.



  • @george1421 You are correct, George. Using the dhcp net0 command did cause the laptop to pick up a DHCP address from my DHCP server. So it seems DHCP is working alright, which like you, I felt confident about since I get an IP address straight away.


  • Moderator

    This still makes me think its a spanning tree issue. I’m a bit surprised that a dumb switch on the target computer’s end didn’t resolve this. In regards to spanning tree, having it on is a good thing, not using one of the fast (opportunistic) protocols (RSTP, MSTP, Fast-STP, etc) is not a good thing.

    For debugging purposes, in your picture above, if you hit the “s” for an ipxe shell prompt then wait 30 seconds and key in dhcp net0 and see if its picks up a dhcp address. You will not be able to continue from here but it will tell us if dhcp is working. I’m suspecting it will get a dhcp address since we can see the mac address of the network adapter so we know the iPXE drivers are loading correctly.



  • @cabraln Try to live-boot a Ubuntu disk/usb-stick on this laptop and see if the wired LAN works or not in the live boot. Also - while livebooted please run this command and give us the full output - it will give us information about the NIC:
    lspci
    Please copy/paste the output if you can so we can easily copy it and do searches.



  • @Wayne-Workman Gave it a try, but same result. :-(



  • @cabraln Please try this: Put a simple un-managed switch (a ‘dumb’ switch) between the laptop and the rest of the network and try again.


 

373
Online

41.8k
Users

12.3k
Topics

116.0k
Posts