HELP! Ethernet card missing after upgrade

Hallo,
I have a strange problem. An old PC is my home server. On the PC I had in the long past 2 NICs. For the last year or so, I had only one NIC installed, a Compex with 8139too module which run just fine.
After the upgrade to 11.4, 32bit of course, with zypper dup, I saw that I had no internet and no network connection to the server.
So, I logged on the server and found that rcnetwork could not start the eth0 and eth3(!).
OK, a mistake I thought. Enter Yast and solve it. Unfortunately, yast reports 2 cards! I removed all of them, rebooted but nothing.
lspci reports 2 cards, while I have NONE installed on the motherboard!
hwinfo --netcard the same!
yast the same!

So, the OS “knows” that I have 2 NICs, while I definitely have none!

Checked if /etc/udev/rules.d/70- had any left data from the past, but the file was empty.
Checked the /etc/sysconfig/network/scripts nothing again.

In principle, the openSUSE 11.4 believes that I have 2 cards (and with wrong MACs, obviously) and I cannot make it rescan the PCI bus to find that I have nothing!

I am sure that some garbages are left somewhere but I don’t know where to look at.
Please help me, it is very critical to have that server but on-line and in my LAN.

We cannot do anything without the output of ‘/sbin/lspci -nnk’

The answer and solution consist in looking/editing (or even creating) the file /etc/udev/rules.d/70-persistent-net.rules and renaming/editing the /etc/sysconfig/network/ifcfg-ethX files. This is (unfortunately) the (IMHO) inconsistent way in which Linux handles network devices (meaning one thing BSD does better) - at some point you would end up with eth452 if you change the netcard often enough without paying attention. But once you know how to rename the nics, it’s easy to fix. Use ifconfig -a to read the MAC addresses and edit the persistent udev rule accordingly. Then rename the ifcfg-etcX files if needed.

Normally openSUSE creates /etc/udev/rules.d/70-persistent-net.rules when the setup detects two netcards during the installation (some distros don’t). The order in which udev numbers the devices may vary however, as it depends on the order the drivers get loaded. Actually, the nics almost systematically appear in a different order. I find it annoying … but one can live with that. On the day when Linux will become perfect, it won’t happen anymore. :wink:

I’m sure YaST can detect and configure the nics. (but I’m an older vi fan).
Actually, how I’m doing it right after a new install is renaming the nics if they don’t appear in the desired order, then reboot and finally configure the network.

The problem is not the renaming. I do know how to do that, but thanks anyway. The problem is that the OS thinks that I have 2 cards installed and I have NONE.

oops … (after I read your post more carefully). Is there a chance that you might have two netcards after all?
Strange indeed. How many nics do you see when booting from a live CD?

Thank God we have the USBs…
Here is the output of lspci -nn:


00:00.0 Host bridge [0600]: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] [1106:0305] (rev 02)
00:01.0 PCI bridge [0604]: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] [1106:8305]
00:07.0 ISA bridge [0601]: VIA Technologies, Inc. VT82C686 [Apollo Super South] [1106:0686] (rev 40)
00:07.1 IDE interface [0101]: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] (rev 06)
00:07.2 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 16)
00:07.3 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 16)
00:07.4 Bridge [0680]: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] [1106:3057] (rev 40)
00:0a.0 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 62)
00:0a.1 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 62)
00:0a.2 USB Controller [0c03]: VIA Technologies, Inc. USB 2.0 [1106:3104] (rev 65)
00:0a.3 RAID bus controller [0104]: VIA Technologies, Inc. VT6421 IDE RAID Controller [1106:3249] (rev 50)
00:0c.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ [10ec:8139] (rev 10)
00:0e.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ [10ec:8139] (rev 10)
01:00.0 VGA compatible controller [0300]: nVidia Corporation NV4 [RIVA TNT] [10de:0020] (rev 04)

and the output of hwinfo --netcard:


09: PCI 0e.0: 0200 Ethernet controller
  [Created at pci.318]
  Unique ID: DkES.bM7cYpCLfi8
  SysFS ID: /devices/pci0000:00/0000:00:0e.0
  SysFS BusID: 0000:00:0e.0
  Hardware Class: network
  Model: "Compex FN22-3(A) LinxPRO Ethernet Adapter"
  Vendor: pci 0x10ec "Realtek Semiconductor Co., Ltd."
  Device: pci 0x8139 "RTL-8139/8139C/8139C+"
  SubVendor: pci 0x11f6 "Compex"
  SubDevice: pci 0x8139 "FN22-3(A) LinxPRO Ethernet Adapter"
  Revision: 0x10
  Driver: "8139too"
  Driver Modules: "8139too"
  Device File: eth3
  I/O Ports: 0xe000-0xe0ff (rw)
  Memory Range: 0xd8002000-0xd80020ff (rw,non-prefetchable)
  IRQ: 11 (2960 events)
  HW Address: 00:c0:26:a4:c1:4d
  Link detected: no
  Module Alias: "pci:v000010ECd00008139sv000011F6sd00008139bc02sc00i00"
  Driver Info #0:
    Driver Status: 8139too is active
    Driver Activation Cmd: "modprobe 8139too"
  Driver Info #1:
    Driver Status: 8139cp is not active
    Driver Activation Cmd: "modprobe 8139cp"
  Config Status: cfg=no, avail=yes, need=no, active=unknown

15: PCI 0c.0: 0200 Ethernet controller
  [Created at pci.318]
  Unique ID: rBUF.bM7cYpCLfi8
  SysFS ID: /devices/pci0000:00/0000:00:0c.0
  SysFS BusID: 0000:00:0c.0
  Hardware Class: network
  Model: "Compex FN22-3(A) LinxPRO Ethernet Adapter"
  Vendor: pci 0x10ec "Realtek Semiconductor Co., Ltd."
  Device: pci 0x8139 "RTL-8139/8139C/8139C+"
  SubVendor: pci 0x11f6 "Compex"
  SubDevice: pci 0x8139 "FN22-3(A) LinxPRO Ethernet Adapter"
  Revision: 0x10
  Driver: "8139too"
  Driver Modules: "8139too"
  Device File: eth0
  I/O Ports: 0xdc00-0xdcff (rw)
  Memory Range: 0xd8000000-0xd80000ff (rw,non-prefetchable)
  Memory Range: 0x30000000-0x3000ffff (ro,prefetchable,disabled)
  IRQ: 10 (5 events)
  HW Address: 00:80:48:2a:21:f5
  Link detected: no
  Module Alias: "pci:v000010ECd00008139sv000011F6sd00008139bc02sc00i00"
  Driver Info #0:
    Driver Status: 8139too is active
    Driver Activation Cmd: "modprobe 8139too"
  Driver Info #1:
    Driver Status: 8139cp is not active
    Driver Activation Cmd: "modprobe 8139cp"
  Config Status: cfg=no, avail=yes, need=no, active=unknown


Again: I have REMOVED the NICs from the Motherboard. It has NO Network cards physically installed on the M/B
openSUSE thinks that I have, obviously, because that info is stored somewhere in the filesystem or a configuration file or whatever…
That’s what I try to find. Where is that info stored…
And yes, I have rebooted the machine a LOT of times.

Could you post the result of the same commands from a live CD? (out of curiosity)

Why? It’s not a HW issue. Believe me I do know what kind of HW I have installed on that PC LONG ago…
I will repost, but I want to know why. Curiosity is not enough…

Latest report:
Removed all entries in /var/lib/hardware/udi/org/freedesktop/Hal/devices (HAL related files) about the Compex card. Still the same answer from both commands…
I report from the live CD soon.

I don’t know why… because it’s weird. I guess it is weird enough to arouse curiousity. Why would hwinfo and lspci read data from some cache or config or whatever? That wouldn’t surely help scanning hardware…

Hal entries only make sense if the hal daemon is running. Hmmm … Is it actually running? It should not (by default on 11.4).

I assume that ifconfig -a reports two nics as well (?)

And what about:

dmesg | grep eth

(?)

From the live cd, the lspci is, of course, OK:

lspci -nn
00:00.0 Host bridge [0600]: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] [1106:0305] (rev 02)
00:01.0 PCI bridge [0604]: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] [1106:8305]
00:07.0 ISA bridge [0601]: VIA Technologies, Inc. VT82C686 [Apollo Super South] [1106:0686] (rev 40)
00:07.1 IDE interface [0101]: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] (rev 06)
00:07.2 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 16)
00:07.3 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 16)
00:07.4 Bridge [0680]: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] [1106:3057] (rev 40)
00:0a.0 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 62)
00:0a.1 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 62)
00:0a.2 USB Controller [0c03]: VIA Technologies, Inc. USB 2.0 [1106:3104] (rev 65)
00:0a.3 RAID bus controller [0104]: VIA Technologies, Inc. VT6421 IDE RAID Controller [1106:3249] (rev 50)
01:00.0 VGA compatible controller [0300]: nVidia Corporation NV4 [RIVA TNT] [10de:0020] (rev 04)

Hmm.
I will stop and disable the HALdaemon.

I am not sure that the /sys, /proc etc are unmounted correctly. I think it is safe to complete wipe them out and reboot, right?

If you look at them from a live system they should ‘normally’ be empty. (?)

Regarding /proc and /sys, here’s what 11.4 uses by default in /etc/fstab:

proc                 /proc                proc       defaults              0 0
sysfs                /sys                 sysfs      noauto                0 0
debugfs              /sys/kernel/debug    debugfs    noauto                0 0
usbfs                /proc/bus/usb        usbfs      noauto                0 0
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0

It starts to be more complicated:
umount /sys:
/sys is not mounted
(!!) Then, why on earth do I see the /sys directory full of entries?

I removed the /sys/pci/bus/devices/… <id of the NIC cards>
Now, the lspci says that it cannot find those 2 directories. So, yes, the lspci reads the /sys.

Then, I did something “crazy”. Removed all subdirectories from /sys except of kernel and rebooted.
Magically, the lspci reported correctly that I had zero network cards.
init 0 and then, I installed the NIC.
Power on, boot and…

I found 1 NIC.
I correctly setup the card and now I have my server back…

Now, that is a strange problem…

It’s that way at least from 11.1 if not earlier…

Yes, but /sys should get populated when /sys get mounted and not contain outdated infos. I think this is the problem you had. On a multiboot machine, here’s what I get while mounting openSUSE root into /suse:

find /suse/proc -ls
215137    4 drwxr-xr-x   3 root     root         4096 Jun  5 01:33 /suse/proc
215138    4 drwxr-xr-x   3 root     root         4096 Jun  5 01:33 /suse/proc/bus
215139    4 drwxr-xr-x   2 root     root         4096 Jun  5 01:33 /suse/proc/bus/usb
root@neelix:~ # find /suse/sys -ls 
183265    4 drwxr-xr-x   3 root     root         4096 Jun  5 01:33 /suse/sys
183266    4 drwxr-xr-x   3 root     root         4096 Jun  5 01:33 /suse/sys/kernel
183267    4 drwxr-xr-x   2 root     root         4096 Jun  5 01:33 /suse/sys/kernel/debug
root@neelix:~ # man sysfs

There is no data left from the openSUSE system I shut down couple minutes ago.

Obviously… I could not think any other place that PCI data are exposed to.
And then it came clear: HAL, udev
But udev was supposed to replace sysfs. So… I should check the /sys.
And found that it had dates from 2009!!!

So, possible explanation: Some time in the past, I moved data from old disk to new disk. In the process I copied the /sys by mistake. So 2 years now, the PC has wrong data! It was a miracle that worked…

Most probable explanation, I would say.