ipxe booting "waiting for the link to come up"

[kvothe88]

@george1421 hi Gorge,

got nothing from that file. No /Failed strings shown, no /failed, no /error or /firmware either with capital letter

[george1421]

@kvothe88 I think I would like to personally see that log file. You can use the scp command on the pxe booting client computer to copy the file to you fog server from there upload it to this thread with a .txt file extension. The command is similar to this scp /var/log/messages root@192.168.1.10:/images Of course change the user and IP address to match your environment. The command will drop the file into /images on the fog server.

ok then lets try one of the one-off kernels that have the updated realtek driver in it.

https://drive.google.com/file/d/1vSu5L-DAZYK7VYiJtFfCYrrqJb963cMg/view?usp=sharing

Download that file from the link and save it as bzImageRT3 in /var/www/html/fog/service/ipxe directory.

Manually register this host with the fog server using the fog web ui then in the host registration page, set the kernel field to bzImageRT3. Save the settings and then pxe boot the target computer into the hardware compatibility check. See if it detects the NIC there.

Also, just so we know the scope, approx how old is this laptop?

[kvothe88]

@george1421 said in ipxe booting "waiting for the link to come up":

bzImageRT3

Hi George! Thanks again.

So, i was not able to move the file to my fog server, that was the error:

Again, i was able to register the host on the fogserver UI. I copied the kernel where you told me and i booted from pxe. Tried the compatibility mode and the bzImageRT3 was using was OK. Got some errors about dell_smbios but unfortunatly the link error showed again:

[george1421]

@kvothe88 Sorry I’m trying to do too many things this AM. Yes scp should have worked, but we have an issue with the NETWORK. So no network functions.

OK will the updated realtek drives in the kernel I sent did not fix the issue. Its still pointing back to the firmware.

If you have a usb flash drive we can use that to get the messages file out of the pxe booted computer.

1. Insert the usb drive into the target computer.
2. issue this command from the debug console
   lsblk
3. I identify the usb flash drive by its size in the list. For the reset of this lets assume it shows up and /dev/sdb
4. Now let make a directory where we can mount that usb drive.
   mkdir /ext
5. Lets connect the usb drive to that directory
   mount /dev/sdb1 /ext
6. That command will mount the first partition on that usb stick to the /ext directory. Issue this command to see the contents of the usb drive
   ls -la /ext
7. If you see what is expected then copy the log file to the use flash drive directory.
   cp /var/log/messages /ext
8. When done unmount that usb drive with
   unmount /ext
9. Now you will be able to remove the usb drive. Don’t remove it before you unmount it and the command completes.

[kvothe88]

@george1421 hi George, thanks for your reply. Here you have the file:

messages.txt

[george1421]

@kvothe88 Just to confirm this is the real mac address of the network adapter in question “60:02:92:3e:ab:7a” ?? The log file is saying the link is down.

Also how old is this computer?

[kvothe88]

@george1421 hi George,

Yes that’s the Mac. Interface is not able to get ip so that makes sense…

Maybe 5, 6 years old

[george1421]

@kvothe88 After much head scratching I understand what is going on here. I don’t have a solution atm, but at least I have an idea.

Realtek has a generic network driver called the r8169. That supports (mostly) a large range of network adapters.

Looking at the boot log of the file you sent me I see this:

r8169 0000:03:00.0 eth0: RTL8106e, 60:02:92:3e:ab:7a, XID 449, IRQ 91

So the real nic is an RTL8106 not an r8168/r8169.

I also found a reference that there is a bug in the R8169 kernel after version 5.4 and the recommendation was to use the 4.19.x series kernel.

ref: https://archived.forum.manjaro.org/t/realtek-rtl810xe-ethernet-not-working-after-kernel-5-4-31/135945/4

it appears the issue was fixed in 5.4.33 (so it should be fixed in 5.6.18).

So what can we do quickly? See if downgrading your linux kernel to 4.19.x allows the system to boot.

[Sebastian Roth]

@kvothe88 @george1421 It’s been busy at work and so I only just saw all your posts. Interesting. From the very first picture you posted we see that enp3s0 is there but says NO-CARRIER and so it seems to not be able to detect the link to be up. Firmware blob does not seem to be an issue from the information posted so far.

Let’s try disabling auto-negotiation for testing to see if that makes a difference. Either do that on the switch if you can or boot into a debug session and run ethtool -s enp3s0 autoneg off - then wait for a bit and check with ip a s to see if it the NO-CARRIER goes away…

[kvothe88]

@george1421 said in ipxe booting "waiting for the link to come up":

e if downgrading your linu

Hi Gorge, and @sebastian-roth

thanks for your reply. I tried all 4.19.x kernels and never worked. Also tried 5.6.x kernel and never worked neither, but…i gave a last shoot to 4.18.11 kernel and BOOOOM! It worked!!

So my question now is…is it possible to download this kernel and make ir usable just for this laptop? and use the newest kernels on the rest of computers¿

Thanks for everything!

[Sebastian Roth]

@kvothe88 said in ipxe booting "waiting for the link to come up":

So my question now is…is it possible to download this kernel and make ir usable just for this laptop? and use the newest kernels on the rest of computers¿

Great you found a kernel that works. Sure you can! Install the kernel you want to use for all your systems. Then manually download the old kernel from our website and put that into /var/www/html/fog/serive/ipxe/ directory on your FOG server. Just keep the name Kernel.TomElliott.4.18.11.64 as downloaded. Not exactly sure if this needs a 64 bit or 32 bit kernel. Do you remember if it loaded bzImage (64 bit) or bzImage32 (32 bit) when PXE booting into a task?

Now edit the host settings of your Toshiba device and set option Host Kernel to Kernel.TomElliott.4.18.11.64 (or …32). When you boot the device up into a task you should clearly see it loading that kernel binary instead of the default bzImage(32).

[kvothe88]

@sebastian-roth Well, ive done it already!

Thanks both of you for your help! I could never been able to figure it out without you! Thanks!