Failed to get an IP via DHCP!

[jes6309]

@george1421 oh I see. Unfortunately the laptop is at work and I have left for the day. I will get the model number for you first thing tomorrow.

[jes6309]

@george1421 HP Model Number: 15-af131dx. Here is the spec sheet http://support.hp.com/id-en/document/c04797004 and here is the hp support/driver page http://support.hp.com/us-en/drivers/selfservice/hp-15-af100-notebook-pc-series/8543365/model/8961406#Z7_3054ICK0K8UDA0AQC11TA930O2.

Thanks again!

[jes6309]

@Wayne-Workman Thank you. I’ve checked and there doesn’t seem to be an issue with the cable/ports. I’ve also tested with known good cables/ports and the results have been the same.

[jes6309]

Update: I just noticed that if I go under fog configuration in the management console, nothing is listed for either bzImage nor bzImage32. When I run the kernal update, I receive the following error: Type: 2, File: /var/www/html/fog/lib/fog/fogftp.class.php, Line: 144, Message: ftp_put(/var/www/html/fog/service/ipxe/bzImage): failed to open stream: No such file or directory.

Is this related?

[Wayne Workman]

@jes6309 I think that’s a separate issue, but easy enough to fix. The FTP credentials used for that are here:
Web Interface -> FOG Configuration -> FOG Settings -> TFTP Server -> FOG_TFTP_FTP_USERNAME & FOG_TFTP_FTP_PASSWORD

If you have only one fog server in your setup, those credentials will be the same as these:
Web Interface -> Storage Management -> [Your storage node] -> Management Username & Management Password

Both of these things and a lot more can be found in the “Troubleshoot FTP” article here:
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

[george1421]

first I have to get this out of the way: Ugh! this has a realtek lan adapter!!

As for your kernels. I see you are running a trunk version. What I would like you to do is manually register this device in FOG. Then schedule a image deployment to this system, BUT make sure you select a debug deployment. This will push the bzImage to the client and the target will boot but drop you at a command prompt.

From there lets use some hardware diagnostics commands to see what network adapter is built in.

[jes6309]

@george1421 Ok I’ve taken these steps, but when the laptop boots to the network, it gets up to “init.xz… ok” and just stops.

[george1421]

@jes6309 (A bit confused now). In your OP you said that when you selected full registration you were getting the “Sending discover…” this should be the FOS kernel running with the virtual hard drive but not able to get a dhcp address. But when you do a debug deploy the system is freezing after the kernel gets the FOS virtual hard drive (init.xz)?

This is a bit inconsistent.

Thinking <…>

[jes6309]

@george1421 hmmmm

idk if this will help, but when I run Kernel Update (after having fixed the credentials as per Wayne) it gets stuck on “Moving to TFTP server…”. If I close out of the operation and attempt to run Kernel Update again, I receive the “Type: 2, File: /var/www/html/fog/lib/fog/fogftp.class.php, Line: 144, Message: ftp_put(/var/www/html/fog/service/ipxe/bzImage): failed to open stream: No such file or directory.” error. On the fog server, if i check /var/www/html/fog/service/ipxe, “bzImage” is nowhere to be found. Note, it was present before attempting the kernel update. It’s as if the kernel update operation is just deleting the bzImage directory rather than actually updating it. I feel like these bizarre errors I’m getting when booting my client to fog and/or registering it as a host has got to be related to a bad kernel, or, after “updating”, a missing kernel.

I’m just at loss for a fix.

[george1421]

@jes6309 ok that is now understandable. I missed the part about the failed update. Let me see if I can get the url to manually download the kernels.

[george1421]

@jes6309

Execute the following commands on the fog server

cd /var/www/html/fog/service/ipxe

wget https://fogproject.org/inits/init.xz
wget https://fogproject.org/inits/init_32.xz
wget https://fogproject.org/kernels/bzImage
wget https://fogproject.org/kernels/bzImage32

This will download the latest (current) kernel and inits.

[jes6309]

@george1421 Ok that got me past “init.xz… ok”

However, I’m getting the “Sending discover…” message again. This is with the debug deploy task scheduled.

[george1421]

@jes6309 Good that should eventually time out (I think) and drop you to the linux shell.

[jes6309]

This post is deleted!

[jes6309]

@george1421 Yup!

[Thu Apr 14 root@fogclient /]# is what I am seeing. What commands did you want me to run?

I went ahead and ran lshw -short and ethernet controller listed is “RTL8101E/RTL8102E PCI Express Fast Ethernet Controller”

[george1421]

@jes6309 OK that is what I expected. I need to ping the @Developers to see if that hardware is in the current FOS kernel since I haven’t seen that one before. We actually need to get the device id. There is a linux command (thinking lspci) that will display the vendor and hardware ID or we can get the same information from a windows system.

<edit> I just checked and its lspci -k I’m suprised that my fog server running centos 7 doesn’t have lspci
ref: https://wiki.fogproject.org/wiki/index.php/Troubleshooting_Driver_Issues
</edit>

[jes6309]

@george1421 Ok here is the info I believe you are looking for:

Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller (rev 07)

Subsystem: Hewlett-Packard Company Device 8137

Kernel driver in use: r8169

[george1421]

@jes6309 There is actually numbers like 8086:1502 that we’ll be looking for. The first group is vendor and the second is hardware id.

lspci -n then you will need to find the network adapter from the description

[jes6309]

@george1421 Ok, I think its 10ec:8136

[Sebastian Roth]

@jes6309 As you can see here this NIC model is supported since kernel version 2.6.x and upwards. So it should not be a driver issue! As well, “Sending discovery…” actually means that we found a network interface and try to get an IP for it via DHCP. So it could be:

• Layer 1 issue like cable (you already checked that)
• Spanning tree issue (make sure you have RSTP or configured “port fast”)
• Auto-negotiation issue (try configuring static speed instead of auto-negotiation for that port)
• Ethernet energy saving (see if your switch has EEE/802.3az feature and disable if possible)