Unable to register and inventory new Dell PCs
-
@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
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
-
@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] -
@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?
-
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.
-
@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.
-
@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.
-
@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.
-
@george1421 OK - I have to deploy these laptops this week but I will try to hold one back for now.
-
@george1421 I’m on it now, booted to 14.04.4 live USB
-
@mattyb Chat…?!
-
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=1Stand by here, lets see how that surface 4 works out.
-
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.
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
-
@Sebastian-Roth So do the new inits work?
-
@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.
-
Adding some more information for later references. Output of
lspci -nn | grep Ethernetshows (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 r81I 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?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
-
@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)?
-
@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.
-
@Sebastian-Roth said:
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
We have a lot of articles that are scattered. I’ll try to at least get the DHCP stuff linked together right now and list all these other articles on the main troubleshooting page.
My main problem with all these other articles is that I’m not sure if they are sound or not. They were created back when the wiki was open to all - so the quality may be questionable.
-
@Wayne-Workman said:
main problem with all these other articles is that I’m not sure if they are sound or not.
Good point! As well there is a lot of pre 1.2.0 stuff in some of the articles which I suspect is more confusing than helping anyone (people who still run 0.32 either know what they do or just don’t care anyway). The best thing to do would be to get together two or three people and do some kind of review. Do you think we could get together with @Tom-Elliott on a chat and start sorting through the wiki?
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
-
@Sebastian-Roth said:
The best thing to do would be to get together two or three people and do some kind of review. Do you think we could get together with @Tom-Elliott on a chat and start sorting through the wiki?
We need to. It needs to be organized like a book - everything in the contents. The search engine is the index.
Old stuff needs to be labeled “OLD” or even removed. I started a list in our secret area already.
