Unable to register and inventory new Dell PCs

[Sebastian Roth]

@mattyb Great! Now we are talking…

• Intel I219-V on the XPS8900: Should be supported in kernel newer than 4.1 (http://cateee.net/lkddb/web-lkddb/E1000E.html - check the PCI ID 8086:15b8). We definitely have the e1000e driver included in the kernel! See in the previous thread where user swhite reported his I219-LM working with kernel 4.1.2. Your I219-V should work as well I am sure.
• The Realtek RTL8168 should be working since kernel version 2.6.19 (http://cateee.net/lkddb/web-lkddb/R8169.html). And we definitely have this driver compiled into our kernel.

Can you please get the very latest kernel again:

mkdir /var/www/html/fog/service/ipxe/backup3
mv /var/www/html/fog/service/ipxe/bzImage* /var/www/html/fog/service/ipxe/backup3
cd /var/www/html/fog/service/ipxe/
wget --no-check-certificate https://fogproject.org/kernels/bzImage -O bzImage
wget --no-check-certificate https://fogproject.org/kernels/bzImage32 -O bzImage32

Register the clients’ MACs by hand in the web interface and schedule a debug task. Boot up the client(s) and make sure you see kernel version 4.4.1 with uname -r.

[george1421]

It looks like the 3470 may use a realtek RTL8151GD This should be the same nic that is used in the Dell 3020 (mid 2014) ven_10ec&dev_8168&subsys_06f21028&rev_0c

The xps8900 appears to use an Intel I219-V ethernet adapter ven_8086&dev_15b8&subsys_06b81028

@mattyb For future reference you can copy and paste the vendor ID into notepad. It would make it easier for us to look up the numbers instead of trying to read a screen shot. (sorry old eyes).

[Sebastian Roth]

@mattyb Although the linux kernel comes with r8169 driver it seams like a lot of people have issues with it. Ask google. A lot of people end up compiling the driver provided by realtek to make their NICs work. See here: https://unixblogger.wordpress.com/2011/10/18/the-pain-of-an-realtek-rtl8111rtl8168-ethernet-card/ (and there are newer references as well)

I will look into building a kernel for you that comes with the realtek driver for testing. Is the Latitude 3470 64 bit arch? I guess so!

[Sebastian Roth]

@george1421 Good catch. Didn’t think there would be another NIC with the exact same PCI ID but named RTL8151GD. Can’t find a linux driver for that one…

@mattyb Just found this: https://en.opensuse.org/SDB:Realtek_8169_driver_problem

[george1421]

@Sebastian-Roth What I’m finding is that RTL8151 (if that is what is really installed in that computer), is an orphan network adapter. The RTL8111 and RTL8169 drivers will not work for it. And so far all I’m seeing is windows only drivers for it.

[edit] interesting, the rtl 8151 (as well as the 8150) may be a usb based network adapter (yes even for LOB).
http://cateee.net/lkddb/web-lkddb/USB_PEGASUS.html This is only one web site, but there are several other references that define this as a usb based network adapter.
[/edit]

[mattyb]

@george1421 Sorry - I was in audit mode and booted it up long enough to grab the requested information.

Following the thread it looks like I’m out of luck for the Latitudes? Can you explain what it means that the NIC is an orphan? Does it literally mean it’s not part of a NIC family with common drivers?

[Scott Adams]

It sounds to me like this might be new UEFI type of BIOS. If that is the case, you would need to make sure that you have a .efi listed as your bootfile option 67 in your DHCP. When dealing with UEFI devices, I currently use ipxe.efi and it seems to work pretty well.

[mattyb]

@Scott-Adams It is UEFI capable, but I’ve disabled it and using classic bios. It actually comes from the factory that way too since it was pre-loaded with a Win7Pro lic.

[Wayne Workman]

@mattyb The boot file you’re using is defined as DHCP option 067 on windows dhcp, and as option next-server in linux ISC-DHCP.

[george1421]

@mattyb said:

Following the thread it looks like I’m out of luck for the Latitudes? Can you explain what it means that the NIC is an orphan? Does it literally mean it’s not part of a NIC family with common drivers?

Out of luck? Not even close yet.

Orphan in the since it is not widely supported. This is something that we haven’t come across yet. So it will take a little detective work on your part to get this sorted out.

What I want you to do now is get a linux live distribution (like ubuntu desktop) that boot that latitude with it. We will need to run a few commands to try to get the proper driver for that device.

[mattyb]

@george1421 OK - I have to deploy these laptops this week but I will try to hold one back for now.

[mattyb]

@george1421 I’m on it now, booted to 14.04.4 live USB

[Sebastian Roth]

@mattyb Chat…?!

[george1421]

If that dell does have a usb nic then we can use what Tom posted here to enable the usb nic in the FOS kernel.

https://forums.fogproject.org/topic/6752/surface-4-network-boot-and-image/22

has_usb_nic=1

Stand by here, lets see how that surface 4 works out.

[Sebastian Roth]

After a long and interesting debugging session we found out that those two NICs (I219-V and yes really a RTL8168, not RTL815x!!!) don’t want to play with FOG 1.2.0. Updating the kernels to current does not help because those NICs don’t seam to come up the way our old FOG 1.2.0 network init script tried to bring them up! Didn’t expect that and went a very long way to find it out. Thanks again to mattyb for being that patient. We booted those machines in debug several times and keyed in the network init commands till I noticed that the older inits are doing something very different.

[Wayne Workman]

@Sebastian-Roth So do the new inits work?

[Sebastian Roth]

@Wayne-Workman Absolutely. We just couldn’t make them work on the old 1.2.0 server. So he installed a new machine with FOG trunk and WHOOOSH the Latitude 3470 went through registering like a charm… Only sad that it took me so long to see that he’s using 1.2.0 as it is noted in the OP.

[Sebastian Roth]

Adding some more information for later references. Output of lspci -nn | grep Ethernet shows (notice PCI ID and revision):

02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 0c)

Looking at dmesg | grep r81 I first thought the NIC is not working because we didn’t have the correct firmware binaries included. BUT it turned out that the NIC was working even without the correct firmware loaded. Possibly not fully functional/speed - I don’t know. Tom added the firmware binary to the current kernel anyway - error disappeared. Here is the dmesg output:

r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:02:00.0 eth0: RTL8168g/8111g at 0xffffc90000062000, 20:47:47:47:bd:76, XID 0c000800 IRQ 273
r8169 0000:02:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
r8169 0000:02:00.0: Direct firmware load for rtl_nic/rtl8168g-2.fw failed with error -2
r8169 0000:02:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168g-2.fw (-2)

To get all these outputs and doing all the testing we booted the ISO file I created some weeks ago (see here or search the forums for ‘grub-mkrescue’). Worked on the first try and was really helpful in this case. I guess we might want to look into adding this to the wiki as well as George’s great posts on creating the USB FOG OS Live (FOSL)?!?

Edit: Ok, I think here would be a good start: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FOG
Should we add Troubleshoot_Boot (which would include iPXE, kernel and init boot)?? I do find scattered information (@Wayne-Workman reminds me on the scattered info on ISC-DHCP settings) on booting process, PXE, iPXE and there is probably a lot more. For example: https://wiki.fogproject.org/wiki/index.php?title=Knowledge_Base#Troubleshooting
But I couldn’t find anything on how to debug the whole booting process. Maybe this is just too complex and every situation is different. So it’s better to handle in the forums?? Comments?

[Tom Elliott]

@Sebastian-Roth I think a wiki article on what to do for troubleshooting may be useful.

I’m also looking at the kernel source. While, for a period of time, the native firmware directory seemed to be missing the firmware files for some nic’s, it appears they are now there (and I don’t know for how long they have been there.

I’m going to attempt building a kernel without the linux-firmware directory I’ve been using for so long in hopes that it may fix the loading issue (maybe it wasn’t ever really needed)?

[Sebastian Roth]

@Tom-Elliott said:

I’m going to attempt building a kernel without the linux-firmware directory I’ve been using for so long in hopes that it may fix the loading issue (maybe it wasn’t ever really needed)?

I really don’t think you should remove all the firmware from the kernel you build!! Which loading issue you mean? The error I posted below? That error went away as soon as I added that particular firmware file to CONFIG_EXTRA_FIRMWARE! I am pretty sure there are some NICs which just won’t work without the firmware binaries. Please think twice before removing them.

I edited my last post to make clear that the error went away when adding the correct firmware to the kernel.