• Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login
  • Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login

i219LM NIC, ASUS Q170M-C Motherboard

Scheduled Pinned Locked Moved
Hardware Compatibility
4
56
22.6k
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • D
    dustindizzle11
    last edited by Sep 23, 2016, 10:56 PM

    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!

    1 Reply Last reply Reply Quote 0
    • G
      george1421 Moderator
      last edited by Sep 23, 2016, 11:54 PM

      Ok lets first remove the obvious. This issue has nothing to do with the iPXE kernel files (undionly.kpxe). The FOS Engine (the linux OS that captures and deploys images on the target computer) is making it to the target computer because you are able to run the compatibility test which is built into the FOS Engine.

      The issue is with FOS engine not having the current drivers for your hardware. What kernels (versions) have you tried. Just recently the developers have made the current kernels (v4.7.x) compatible with the older version of FOG. There was a gap between 4.3.x and 4.6.x where those newer kernels were not compatible with FOG 1.2.0 stable. I can say I ran FOG 1.2.0-trunk and now 1.3.0-rcX series and that network adapter is supported.

      If you were running fog 1.3 or the 1.2.0 trunk release I would ask you to manually register that computer then schedule a debug capture of that computer. I think fog 1.2.0 had this but you had to access it via the advanced menu on the host registration page (stated from memory). Then you pxe boot that target computer. The FOS engine should be transferred to the target computer and then display some instructions on the screen. After several presses of the enter key it should drop you to a command prompt. From there we can start debugging.

      One last thing I can think of is if your building switch has spanning tree turned on you must use one of the fast STP protocols like (fast stp, rstp, or port fast). As the target computer boots it winks (momentarily drops the network link) as the iPXE kernel (undionly) hands over control to the FOS Engine. This momentary wink causes spanning tree to not forward data for 27 seconds. By the time spanning tree starts to forward data the FOS Engine has already given up. A quick check to see if this is a spanning tree issue is to place a unmanaged switch between the building switch and the booting target computer. The unmanaged switch will keep the building switch port from winking as the FOS Engine starts.

      Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

      1 Reply Last reply Reply Quote 0
      • D
        dustindizzle11
        last edited by Sep 27, 2016, 6:34 PM

        Thanks for the response. It is not spanning tree, so I have eliminated that.

        I have tried lots of kernels, but here is a list of a few…

        4.6.2.64
        4.7.0.64
        4.7.3.64
        latest bzImage

        If I do a download debug task, when at the shell prompt I noticed that if I run “ifconfig” to see my interface and ip address, there is no interface listed and therefore no address. Just the loopback device (just seemed odd)…I can see that eth0 is an option from the command “ip link show”. What can I do to debug this? Thanks for your time.

        Dustin

        G 1 Reply Last reply Sep 27, 2016, 6:45 PM Reply Quote 0
        • G
          george1421 Moderator @dustindizzle11
          last edited by Sep 27, 2016, 6:45 PM

          @dustindizzle11 OK now that you are at the debug console I want you to key in the following command lspci -nn

          What I’m looking for is the ethernet controller line. This one is from my fog server.

          0b:00.0 Ethernet controller [0200]: VMware VMXNET3 Ethernet Controller [15ad:07b0] (rev 01)
          

          The key is the 8 hex keys “[15ad:07b0]” that will be the nic hardware manufacturer and the device ID. You can also view these values from a running windows system this is the vendor and hardware id in the device manager, but since you have the debug console that is the best way to get that information.

          Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

          D 1 Reply Last reply Sep 27, 2016, 6:54 PM Reply Quote 0
          • D
            dustindizzle11 @george1421
            last edited by Sep 27, 2016, 6:54 PM

            @george1421

            I don’t get the expected output from running lspci -nn (or by using the -vv option which displays the same thing. Pic below)

            0_1475002421834_20160927_115207.jpg

            G 1 Reply Last reply Sep 27, 2016, 6:55 PM Reply Quote 0
            • G
              george1421 Moderator @dustindizzle11
              last edited by Sep 27, 2016, 6:55 PM

              @dustindizzle11 Try with just one -n I know one of the command line switches should give the output like I posted. -nn worked on centos 7.

              Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

              D 1 Reply Last reply Sep 27, 2016, 6:59 PM Reply Quote 0
              • D
                dustindizzle11 @george1421
                last edited by dustindizzle11 Sep 27, 2016, 1:00 PM Sep 27, 2016, 6:59 PM

                @george1421
                one “-n” gives me the same thing 😞 … “ip link show” lists eth0 though for some reason.

                Also, Side note, I am using the 4.6.2 Kernel at the moment with debug on.

                1 Reply Last reply Reply Quote 0
                • T
                  Tom Elliott
                  last edited by Sep 27, 2016, 7:20 PM

                  Is the VM setup for natted interface when it should be bridged?

                  Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.

                  Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                  Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                  D 2 Replies Last reply Sep 27, 2016, 7:45 PM Reply Quote 0
                  • D
                    dustindizzle11 @Tom Elliott
                    last edited by Sep 27, 2016, 7:45 PM

                    @Tom-Elliott
                    It is bridged.

                    G 1 Reply Last reply Sep 27, 2016, 7:49 PM Reply Quote 0
                    • G
                      george1421 Moderator @dustindizzle11
                      last edited by george1421 Sep 27, 2016, 1:51 PM Sep 27, 2016, 7:49 PM

                      @dustindizzle11 said in i219LM NIC, ASUS Q170M-C Motherboard:

                      @Tom-Elliott
                      It is bridged.

                      What, where did a virtualization layer come into scope? My assumption was the FOG Engine was running directly on the hardware.

                      Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

                      T 1 Reply Last reply Sep 27, 2016, 7:54 PM Reply Quote 0
                      • T
                        Tom Elliott @george1421
                        last edited by Sep 27, 2016, 7:54 PM

                        @george1421 I think the problem system is physical just the fog server is a VM.

                        Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.

                        Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                        Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                        1 Reply Last reply Reply Quote 0
                        • D
                          dustindizzle11 @Tom Elliott
                          last edited by Sep 27, 2016, 7:57 PM

                          @Tom-Elliott

                          If I go into debug mode and manually enable the interface, then restart networking it works (after getting eth0 added and typing “fog” in debug mode, the computer images fine). The problem is that for some reason, eth0 is not setup as an interface.

                          So all I did manually was…

                          ifconfig eth0 up

                          added to /etc/network/interfaces

                          auto eth0
                          iface eth0 inet dhcp

                          then /etc/init.d/S40network restart

                          I probably could have just added it to the interfaces file and restarted to get it an address, but wanted to show what I did above. Also I am not sure that the name was “S40network”, i just remember it being called S40"something".

                          Anyone have any ideas as to why it is not getting added automatically?

                          T G 2 Replies Last reply Sep 27, 2016, 8:35 PM Reply Quote 0
                          • T
                            Tom Elliott @dustindizzle11
                            last edited by Sep 27, 2016, 8:35 PM

                            @dustindizzle11 S40network is the correct init.d script to call.

                            That said, can you try putting a “dummy” switch between the main and the system you’re having issues with?

                            See your info tells me the link up is not being detected, which is usually a STP portion issue. That or the patch cable isn’t returning “link up”.

                            Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.

                            Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                            Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                            D 1 Reply Last reply Sep 27, 2016, 9:35 PM Reply Quote 0
                            • G
                              george1421 Moderator @dustindizzle11
                              last edited by Sep 27, 2016, 8:54 PM

                              @dustindizzle11 I agree with Tom. What we’ve seen is that if the building switch has Spanning Tree enabled and the switch is not configured for one of the fast spanning tree modes the FOS engine will boot, wait and give up before spanning tree starts forwarding data. On your building switch you need to check to see if STP is enabled, if it is you need to enable one of the fast spanning tree protocols (port fast, RSTP, fast STP, or what ever your switch mfg calls it).

                              One quick check to see if it is a spanning tree issue, is to put an dumb (unmanaged) switch between the target computer and the building switch and then pxe boot the target computer. That unmanaged switch will keep the building switch from seeing the target nic wink (momentarily drop the port link) as the target transitions from the iPXE kernel to the FOS Engine kernel.

                              Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

                              D 1 Reply Last reply Sep 27, 2016, 9:39 PM Reply Quote 0
                              • D
                                dustindizzle11 @Tom Elliott
                                last edited by Sep 27, 2016, 9:35 PM

                                @Tom-Elliott

                                There is currently already a dummy switch in between. I can image any other model from the same spot, just this model behaves this way.

                                1 Reply Last reply Reply Quote 0
                                • D
                                  dustindizzle11 @george1421
                                  last edited by Sep 27, 2016, 9:39 PM

                                  @george1421

                                  We have port fast enabled on all ports

                                  T 1 Reply Last reply Sep 28, 2016, 11:51 AM Reply Quote 0
                                  • T
                                    Tom Elliott @dustindizzle11
                                    last edited by Sep 28, 2016, 11:51 AM

                                    @dustindizzle11 Do you have other systems of the same model MB? Does this happen in the same way for all systems, or just this one system?

                                    Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.

                                    Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                                    Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                                    D 1 Reply Last reply Sep 28, 2016, 4:37 PM Reply Quote 0
                                    • D
                                      dustindizzle11 @Tom Elliott
                                      last edited by Sep 28, 2016, 4:37 PM

                                      @Tom-Elliott Yes we have other systems with the same model MB. This happens in the same way for all systems that have this MB. Thanks again for trying to help with this, I appreciate the time you guys take to help troubleshoot. It is strange that it is not auto configuring eth0. Btw, when in debug mode just adding eth0 to the interfaces file then restarting the network is all that needs to be done to get an address and fog the computer. Just mentioning that because I mentioned in an earlier comment what I did to get an address, which was more than I needed to do.

                                      T 1 Reply Last reply Sep 28, 2016, 4:42 PM Reply Quote 0
                                      • T
                                        Tom Elliott @dustindizzle11
                                        last edited by Sep 28, 2016, 4:42 PM

                                        @dustindizzle11 the s40 file you referenced is supposed to do this for you but it only adds the interface I’d the nic has a cable attached (or shall I say recognizes the link is up). And I suspect this is where it’s failing. It can’t detect the link for whatever reason.

                                        Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.

                                        Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                                        Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                                        G 1 Reply Last reply Sep 28, 2016, 5:04 PM Reply Quote 0
                                        • G
                                          george1421 Moderator @Tom Elliott
                                          last edited by Sep 28, 2016, 5:04 PM

                                          @Tom-Elliott I thoght that either Sabastian or you added a loop to the network startup code where it would check wait, and then check again for the a link or dhcp packet to be received before giving up on the interface. This was done to mask the spanning tree issue (I know this is not the case here) but it would seem the network link is slow to come up for some reason.

                                          Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

                                          D 1 Reply Last reply Sep 28, 2016, 9:14 PM Reply Quote 0
                                          • 1
                                          • 2
                                          • 3
                                          • 1 / 3
                                          1 / 3
                                          • First post
                                            8/56
                                            Last post

                                          276

                                          Online

                                          12.0k

                                          Users

                                          17.3k

                                          Topics

                                          155.2k

                                          Posts
                                          Copyright © 2012-2024 FOG Project