Unable to register and inventory new Dell PCs
-
@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.
-
@Sebastian-Roth I would like to thank Sebastian for his time in helping me diagnose this issue. We spent a substantial amount of time working through the issue and I learned a lot through the process! We are working through uploading images for these two machines as I type and all appears to be going well now that I’m on the Trunk version.
-
I’m getting the Trunk-specific database error when uploading an image (same as referenced in the WIKI here. I’ve checked all four locations for the correct username/password combination and it’s correct. I’ve checked the filesystem of the new FOG server that Sebastian walked me through, and it’s the correct EXT4. Username ‘Root’ has seems to have the proper system access to the image directory that it needs based on the result of the ls -laR /images command.
-
@mattyb said:
Username ‘Root’ has seems to have the proper system access to the image directory that it needs based on the result of the ls -laR /images command.
The username that is used in all of the credentials you checked must have system access to the image directory.
Can you try to log into the server via FTP using the credentials you confirmed? There are examples of how to do this towards the top of that article. Do it from a remote computer - not from the fog server.
-
@Wayne-Workman Logging in to ftp://<IP> works fine, I can read and write. Do I need to test at the specific image directory?
-
@mattyb It wouldn’t hurt.
Anything in the apache error logs?
FOG Configuration -> Log Viewer -> Apache Error Log -
@Wayne-Workman Interesting. Navigating to fog Configuration / Log Viewer straight away says there’s an error with the Fog “ftp_login(): Login incorrect.”
In my Fog Configuration / TFTP Server, the username and password are correct, as are the fog config files on the server.
