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.
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.
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)
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.
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 (?)
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)
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…
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:
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…