Hi Everyone,
I have suddenly lost my built-in Ethernet adapter ( not visible in Settings > Network ). The machine is a Dell Optiplex desktop.
Maybe there is a way to re-invoke the nic detection as when installing Fedora 40 ?
When doing “cat /proc/net/dev” I cannot see the adapter.
When doing “ifconfig” I cannot see the adapter.
When doing “nmcli device” I cannot see the adapter.
But it was working before and it was present !
Scratching my head.
Does it show in the output of lspci? If not, then maybe a kernel module (driver) isn’t loaded?
If it happened after you updated your system, you might try booting your previous kernel and see if the network device shows up again.
If your network adapter changes PCI location (something like changing an IOMMU BIOS option), NetworkManager creates a new profile for the “new” device. It sounds like your network card is entirely not visible though?
Hi,
I do seem to see it when doing ‘lspci’ . It is listed as "Enternet controller: Intel corporation ethernet connection I217-LM )rev 04)’ . What should I do next ?
If it shows in the output from lspci, I think it should show in the output from ip address list. If it is there, then I don’t know why NetworkManager wouldn’t be seeing it and configuring it.
Is the NetworkManager service running? What does the output from systemctl status NetworkManager.service show?
Hi ,
ip address list only shows my usb ethernet adapter. Not the ibm one.
systemctl status network manager shows the usb ethernet adapter also, but not the built-in ibm one.
I don’t think I’ve ever encountered a situation where a network device showed in lspci, but not in ip address list. Try greping your device message log for your NIC’s PCI address. For example, when I run lspci, I see that my NIC is on PCI bus 3, device 0:
$ lspci -k -s 03:00.0
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
Subsystem: Lenovo Device 364f
Kernel driver in use: r8169
Kernel modules: r8169
If I grep the output from the dmesg command for that PCI address, I can see some status messages from when the driver initialized the device:
$ sudo dmesg | grep 03:00.0
[ 0.396408] pci 0000:03:00.0: [10ec:8168] type 00 class 0x020000 PCIe Endpoint
[ 0.396429] pci 0000:03:00.0: BAR 0 [io 0xd000-0xd0ff]
[ 0.396455] pci 0000:03:00.0: BAR 2 [mem 0xfe800000-0xfe800fff 64bit]
[ 0.396479] pci 0000:03:00.0: BAR 4 [mem 0xf0800000-0xf0803fff 64bit pref]
[ 0.396579] pci 0000:03:00.0: supports D1 D2
[ 0.396580] pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 2.748205] r8169 0000:03:00.0 eth0: RTL8168g/8111g, 00:d8:61:b7:f2:53, XID 4c0, IRQ 38
[ 2.748214] r8169 0000:03:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[ 2.843765] r8169 0000:03:00.0 enp3s0: renamed from eth0
[ 32.091878] r8169 0000:03:00.0 enp3s0: Link is Down
[ 32.186722] r8169 0000:03:00.0 enp3s0: entered promiscuous mode
[ 34.896327] r8169 0000:03:00.0 enp3s0: Link is Up - 1Gbps/Full - flow control rx/tx
I can see that the device ended up being named “enp3s0” (which corresponds to its PCI address) and that is the name that it is listed under in the output of ip address list:
$ ip address list enp3s0
2: enp3s0: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:d8:61:b7:f2:53 brd ff:ff:ff:ff:ff:ff
You should get the PCI ID string (probably like: 8086:153A:???:???) and check that it is supported by the e1000e module:
modinfo e1000e| grep 'pci:v00008086d0000153A'
alias: pci:v00008086d0000153Asv*sd*bc*sc*i*
Then try modprobe -n -v e1000e (for explanation, see man modprobe).
Decades ago at work NFS data transfers were failing on one a desktop PC, but other network protocols were working. I opened up the box and discovered burned components on the ethernet card. I consider network adapters disposable. They are cheap and failure prone,
so “when in doubt, throw it out”.