i219LM NIC, ASUS Q170M-C Motherboard



  • Not sure if anyone has ran into this, but I have not been able to get these CTL computers to image. As the title states, they have a i219LM NIC, on an ASUS Q170M-C Motherboard. The computers will grab ipxe fine initially, but hit a black screen when trying to send an image or register them with FOG. I have checked the FOG Compatibility checker within the menu, and it states that these computers are not compatible with FOG. I use Fog 1.2… Things I have tried are…

    0_1474671082064_20160923_155014.jpg

    • Trying a bunch of different Kernels (including the latest from https://fogproject.org/kernels/). I am positive that the newer kernels were being used too,. I gave them totally different names in the /var/www/fog/service/ipxe/ directory, and I can see them loading when booting.

    • Trying different ipxe files (I use undionly.kkpxe, but tried the others in tftpboot, along with the latest trunk ipxe files in combination with the above latest kernels)

    • Made sure that it is legacy booting, not UEFI…

    I have used FOG for quite a while, and as the compatibility checker states, I think it is a kernel issue. Does anyone have any ideas or experience with this NIC? I I appreciate any help. If anything, I am just letting others know that this NIC is giving me issues. Thanks!


  • Developer

    @dustindizzle11 Sorry for my late reply. There is a side way you could go with this now that you know how to modify the init.xz image. Grep yourself a copy of the current script and exchange the one you posted with this new one. See if you can make it work with this. Just an idea for a quick dirty fix.


  • Senior Developer

    @dustindizzle11 I totally understand.



  • @Tom-Elliott I will eventually (and want to). The reason for reservations on upgrading Fog right now is because I am not wanting to fight through all the things that can break when upgrading my live system (not saying it would, just there’s a chance). I work for a school district so I would rather test things before-hand to ensure the system is still functional if it is needed.


  • Senior Developer

    @dustindizzle11 I would highly recommend updating to RC-14, unless there’s a particular reason for the reservations?



  • @Tom-Elliott Ok. I will just leave this as is then unless there is something you guys want me to do. Thanks for all


  • Senior Developer

    @dustindizzle11 No. 1.2.0 didn’t even use detection of interfaces to get IP information. This is likely why you’re not seeing it as a “success” in the compatibility either.



  • @Tom-Elliott No, not on my live fog system. This has fog 1.2. Is the RC S40 script still applicable if I am able to get it?


  • Senior Developer

    I made this change for the RC’s. Unfortunately the installer for the FOG 1.2 did not have this possibility. I was under the impression you were running on the RC versions.



  • @Tom-Elliott I installed Fog1.2 on another system and copied over the init.xz to my current fog setup. After sending the image, it just zipped through to a black screen again :( . So it did the same thing that it did before. shoot…

    @Sebastian-Roth Below is the S40network contents from my original init.xz…

    #!/bin/sh

    Start the network…

    case “$1” in
    start)
    echo “Starting network…”
    /sbin/ifup -a
    ;;
    stop)
    echo -n “Stopping network…”
    /sbin/ifdown -a
    ;;
    restart|reload)
    "$0" stop
    "$0" start
    ;;
    *)
    echo "Usage: $0 {start|stop|restart}"
    exit 1
    esac

    exit $?


  • Senior Developer

    I’ve updated the S40network script to use a case insensitive approach.

    The beauty is all you need to do to test it is rerun the installer and you will have the latest init.

    Please update if you can and let us know if it’s working any better.


  • Developer

    @dustindizzle11 Looks all good to me too. So even more I am wondering why you don’t see the waiting time when setting the has_usb_nic parameter… Possibly this is an older version of the init.xz file (maybe from FOG 1.2.0 when I look at the size of just about 10 MB??). The most current one is around 17 MB (more drivers). So I am pretty sure this is what’s going on.

    As you already know how to modify the init.xz file please do so and copy & paste the full content of the file etc/init.d/S40network extracted from the init.xz file you have.



  • @Sebastian-Roth Yes, I named it “4.6.2” in “/var/www/{,html}/fog/service/ipxe/”. I am positive the kernel file is named correctly and that it loads when PXE booting. Below are the screenshots you requested.

    1_1476285820772_fog2.JPG 0_1476285820771_fog1.JPG


  • Developer

    @dustindizzle11 Is your kernel file actually named 4.6.2? What do you see when running ls -al /var/www/{,html}/fog/service/ipxe/?

    As well would you mind posting a sceenshot of the host settings where we see the MAC address as well. I just want to make sure that we are not running in circles not seeing the obvious reason…




  • Developer

    @dustindizzle11 said:

    I didn’t get any messages about re-plugging the USB NIC in though. Let me know if you need to me try anything else.

    Well then there is no delay and you will run into the same issue again and again I am sure. Can you please post a screenshot of the host kernel setting in the web GUI…



  • @Sebastian-Roth I added “has_usb_nic=1” to the Host Kernel Arguments section and it did the same thing it would do before, which is just zip to a black screen. This is the behavior I get when I don’t get an address. I am using the 4.6.2 Kernel. I didn’t get any messages about re-plugging the USB NIC in though. Let me know if you need to me try anything else.


  • Senior Developer

    @Sebastian-Roth I say it isn’t timing not because it couldn’t be, but rather I think the device is there but for whatever reason the carrier link is unrecognized. So I think to further test this theory we would need to see the carrier state not the simple ip command. If it is timing that’s alright as we just increase wait time and all should work fine. If it’s not then I think we need to figure out why the carrier link is unseen.


  • Developer

    @Tom-Elliott This definitely looks like a timing issue to me. As he said th last picture is from starting the original init.xz in debug and then running ip command without any other actions I suppose. As we see in the picture the interface eth0 is shown properly. So I am pretty sure that it is timing. The interface is not “available” on kernel driver load time straight away but somehow delayed…

    @dustindizzle11 Thanks again! Can you please try the following stuff: Use the original init.xz and add has_usb_nic=1 to the kernel parameters in the host configuration for one of your test clients having this issue. Then when you boot up the client it asks you to replug the (USB-)NIC. Just ignore the message, wait for 10 seconds and hit ENTER to proceed. Does it solve the issue?!



  • @Sebastian-Roth Original


 

487
Online

41.7k
Users

12.2k
Topics

115.1k
Posts