Unable to register and inventory new Dell PCs

[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.

[Wayne Workman]

@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.

[Sebastian Roth]

@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?

[Wayne Workman]

@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.

[mattyb]

@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.

[mattyb]

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.

[Wayne Workman]

@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.

[mattyb]

@Wayne-Workman Logging in to ftp://<IP> works fine, I can read and write. Do I need to test at the specific image directory?

[Wayne Workman]

@mattyb It wouldn’t hurt.

Anything in the apache error logs? FOG Configuration -> Log Viewer -> Apache Error Log

[mattyb]

@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.

[Wayne Workman]

@mattyb The error should show you what it tried for the username and password. navigate back to the log viewer and pay attention to the error.

[mattyb]

@Wayne-Workman There’s nothing to expand. Below the pause button it says ‘invalid folder’ and nothing else.

[mattyb]

I think my issue is in Storage Node / DefaultMember / Management Password. I updated that to match all other configs and now I get actual log choices. Trying to upload now.