[SOLVED] Slackware 15.0 move hard drive to new hardware network interfaces not working

rocknrobin · 09-01-2023, 05:43 PM

Hello again...I am running a Slackware 15.0 distro and recently had a catastrophic failure on the desktop pc where it resides. It appeared to me the MB had bit the dust. I ordered a new desktop with no hard drives or OS thinking I could just plug the Slackware hard drive in and it would take off. I was connected to the console and I could see it boot, but no network interfaces came up. On the old machine I had an onboard NIC in the MB which came up as eth0 and a usb to Ethernet adapter which was eth1. On the new hardware When running ifconfig only the 127.0.0.0 interface came up and of course no access to the outside world. After doing much reading it has become apparent that the interface names had changed compared to the MAC addresses for the ethernet interfaces. I was able to boot up to an Lubuntu thumb drive and the eth0 interface came up and was talking. The eth1, the usb to lan adapter, did not however come up. I believe the new hardware does not recognize the Belkin adapter because running lsusb does not list the adapter like on this other Slackware hardware I have.

Code:

root@robrutrm:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 007: ID 1b1c:0c1a Corsair CORSAIR Lighting Node CORE
Bus 001 Device 003: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 021: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet
Bus 001 Device 020: ID 2109:2817 VIA Labs, Inc. USB2.0 Hub
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 005: ID 048d:5702 Integrated Technology Express, Inc. ITE Device
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Therefore I am going to leave the eth1 problem alone for now. I would like to get eth0 going initially. As further info when I look at /etc/udev/rules.d when running Lubuntu from the thumb drive. I only see these files:

Code:

robby@rob-ep45ud3p:/etc/udev/rules.d$ ls -l
total 68
-rw-r--r-- 1 root root 63312 Jun  9  2022 70-snap.snapd.rules
-rw-r--r-- 1 root root   989 Jun  9  2022 70-snap.vlc.rules

Therefore I am assuming that Ubuntu does not use the persistent files and configures the network interfaces "on the fly" at bootup. Please correct me if I'm wrong.

When I ran ifconfig -a on the problem box I got this output.

Code:

root@robrutrm:/etc/rc.d# ifconfig -a
eth2: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether 98:90:96:c5:3b:5e  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory 0xf7c00000-f7c20000

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 13101  bytes 1605430 (1.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 13101  bytes 1605430 (1.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I see from these commands that the on board ethernet NIC is recognized on bootup...

Code:

root@robrutrm:/etc/rc.d# dmesg | grep -i ETH
[    8.554172] wmi_bus wmi_bus-PNP0C14:01: WQBC data block query control method not found
[   10.146139] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 98:90:96:c5:3b:5e
[   10.146226] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[   10.146319] e1000e 0000:00:19.0 eth0: MAC: 11, PHY: 12, PBA No: FFFFFF-0FF
[   12.062182] e1000e 0000:00:19.0 eth126: renamed from eth0
[   12.074925] e1000e 0000:00:19.0 eth2: renamed from eth126
[44280.755415] usbcore: registered new interface driver cdc_ether
[44280.945069] cdc_ncm 2-1.5.3:2.0 eth0: register 'cdc_ncm' at usb-0000:00:1d.0-1.5.3, CDC NCM (NO ZLP), f8:e4:3b:5a:b0:a1
[44280.980639] cdc_ncm 2-1.5.3:2.0 eth125: renamed from eth0
[44280.995507] cdc_ncm 2-1.5.3:2.0 rename_eth125: renamed from eth125
[44370.454387] cdc_ncm 2-1.5.3:2.0 rename_eth125: unregister 'cdc_ncm' usb-0000:00:1d.0-1.5.3, CDC NCM (NO ZLP)
[44370.478473] udevd[7699]: Error changing net interface name rename_eth125 to eth2: No such device
root@robrutrm:/etc/rc.d# dmesg | grep -i network
[   10.009981] e1000e: Intel(R) PRO/1000 Network Driver
[   10.146226] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection

From the ifconfig -a output above I see a MAC address of 98:90:96:c5:3b:5e for eth2 and from the parsed dmesg output I see an ethernet NIC is recognized with the same MAC address. When I look at /etc/udev/rules.d I see these files...

Code:

root@robrutrm:/etc/udev/rules.d# ls -l
total 8
-rw-r--r-- 1 root root 2630 Mar  1  2022 70-persistent-cd.rules
-rw-r--r-- 1 root root  370 Mar  3  2022 70-persistent-net.rules

Here is what my 70-persistent-net.rules file has in it.

Code:

# PCI device 0x1969:/sys/devices/pci0000:00/0000:00:1c.1/0000:01:00.0 (atl1c)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="f4:6d:04:1a:64:0d", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# USB device 0x0b95:0x7720 (usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:b6:0a:e7:a7", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# USB device 0x0b95:0x1790 (usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="f8:e4:3b:5a:b0:a1", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

Evidently what is in the 70-persistent-net.rules files MAC address for eth0 does not match what is the new hardware MAC address for the ethernet NIC. Also what I have been able to decipher from different posts is to "edit" the 70-persistent-net.rules file and then reload the rules. By edit does it mean to just change the MAC address in the 70-persistent file and then how do I go about reloading the rules? ...or is there a better way to make these changes so they are more dynamic? Thanks in advance.

lostintime · 09-01-2023, 09:26 PM

Try deleting 70-persistent-net.rules and rebooting.

henca · 09-02-2023, 03:56 AM

Yes, deleting the file and reboot will work. Another quicker fix than changing the long mac-adresses on the lines would be to change the interface names at the end of those long lines and reboot.

From:

Code:

# PCI device 0x1969:/sys/devices/pci0000:00/0000:00:1c.1/0000:01:00.0 (atl1c)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="f4:6d:04:1a:64:0d", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# USB device 0x0b95:0x7720 (usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:b6:0a:e7:a7", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# USB device 0x0b95:0x1790 (usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="f8:e4:3b:5a:b0:a1", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

To:

Code:

# PCI device 0x1969:/sys/devices/pci0000:00/0000:00:1c.1/0000:01:00.0 (atl1c)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="f4:6d:04:1a:64:0d", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

# USB device 0x0b95:0x7720 (usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:b6:0a:e7:a7", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# USB device 0x0b95:0x1790 (usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="f8:e4:3b:5a:b0:a1", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

As the old MB with its NIC is fried you can also remove the line with f4:6d:04:1a:64:0d completely, you will never get an interface with that MAC address again.

Editing the file instead of deleting it will make sure that your old USB NIC is rememberd as eth1. However, the next question is why that one does not work with your new motherboard. Does the USB ports it is connected to work with other USB devices? Does the USB NIC work in another computer? Maybe the USB NIC got fried when your old MB got fried?

regards Henrik

rocknrobin · 09-10-2023, 05:56 PM

All working ok now. I did not try deleting the 70-persistent-net.rules as suggested by lostintime.

I did try swapping device names between eth0 and eth2 as suggested by henca. All that did was add a device eth3 with the NAC address of 98:90:96:c5:3b:5e which is the MAC address of the onboard Ethernet NIC of the motherboard. That did not allow Ethernet connectivity to the network either...it did not even cause the link and activity lights to flash on the Ethernet connector.

I then substituted the MAC address 98:90:96:c5:3b:5e as the eth0 device in the 70-persistent-net.rules file as such.

Code:

# PCI device 0x1969:/sys/devices/pci0000:00/0000:00:1c.1/0000:01:00.0 (atl1c)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="98:90:96:c5:3b:5e", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# USB device 0x0b95:0x7720 (usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:b6:0a:e7:a7", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

After reboot eth0 came up working with link and activity lights on the Ethernet interface and network connectivity.

I then moved on to the USB to Ethernet adapter. I had a new PC with a newer USB to Ethernet adapter connected to it, the original USB to Ethernet adapter was probably 7 or 8 years old, and upon connecting the new adapter to a USB port on the problem linux box it was recognized via lsusb. Once again though since the MAC addresses did not line up in the 70-persistent-net.rules file the network connectivity still did not work. I then ordered a similar USB to Ethernet adapter that was recognized to replace the older one. Upon initial install via a USB port in the problem Linux box the USB to Ethernet adapter was recognized, but generated this 70-persistent.rules file.

Code:

# PCI device 0x1969:/sys/devices/pci0000:00/0000:00:1c.1/0000:01:00.0 (atl1c)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="f4:6d:04:1a:64:0d", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# USB device 0x0b95:0x7720 (usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:b6:0a:e7:a7", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# USB device 0x0b95:0x1790 (usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="f8:e4:3b:5a:b0:a1", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

The MAC address 00:50:b6:0a:e7:a7 was the MAC address of the old usb to Ethernet adapter.

After checking that I ran dmesg to get the MAC address of the new USB to Ethernet adapter.

Code:

root@robrutrm:/etc/udev/rules.d# dmesg | grep -i eth
[    8.696499] wmi_bus wmi_bus-PNP0C14:01: WQBC data block query control method not found
[   10.204272] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 98:90:96:c5:3b:5e
[   10.204389] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[   10.204502] e1000e 0000:00:19.0 eth0: MAC: 11, PHY: 12, PBA No: FFFFFF-0FF
[   14.234279] usbcore: registered new interface driver cdc_ether
[   14.448778] cdc_ncm 2-1.5:2.0 eth1: register 'cdc_ncm' at usb-0000:00:1d.0-1.5, CDC NCM (NO ZLP), 08:26:ae:3c:22:17
[   35.513071] e1000e 0000:00:19.0 eth0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[   35.513111] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

I then substituted the new MAC address, 08:26:ae:3c:22:17, for the old one, 00:50:b6:0a:e7:a7 in the 70-persistent-net.rules file as such.

After reboot the onboard NIC and the USB Ethernet adapter are both working again.

Code:

# PCI device 0x1969:/sys/devices/pci0000:00/0000:00:1c.1/0000:01:00.0 (atl1c)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="98:90:96:c5:3b:5e", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# USB device 0x0b95:0x7720 (usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:26:ae:3c:22:17", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# USB device 0x0b95:0x1790 (usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="f8:e4:3b:5a:b0:a1", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

If I'm not mistaken the eth2 device and its associated MAC address are the entry in the file for the internal CD/DVD drive. At any rate all is working again. I am not sure if substituting MAC addresses in the 70-persistent-net.rules file is the only way to fix this issue when hardware is changed, but it must be one way. I am assuming, correct me if I'm wrong, that the reason for the persistent files is to speed up boot time as the modules do not have to be probed every time the machine is rebooted or powered up? This thread can be marked as SOLVED. Thanks for all the help.

henca · 09-11-2023, 12:47 AM

Quote:

Originally Posted by rocknrobin

correct me if I'm wrong, that the reason for the persistent files is to speed up boot time as the modules do not have to be probed every time the machine is rebooted or powered up?

I think that the main reason for that file is to avoid that your old ethernet interfaces get renamed when adding a new ethernet interface. You would probably find it slightly annoying if you temporary added one more USB ethernet interface and the new USB interface got named eth0 and all you old existing interfaces got 1 added to their numbers. This file will make sure that new interfaces not seen before by the computer get the next available interface name.

regards Henrik

rocknrobin · 09-11-2023, 10:32 AM

Thanks Henrik, that does make sense. And FYI I tried the old usb to Ethernet adapter that wasn't recognized with the new hardware on an older PC I built 7 or 8 years ago, Windows 10 OS, and it worked.

nnx · 02-29-2024, 05:48 PM

Dear Forum,
I had a similar issue and lost my ethernet after replacing the mainboard. Everything worked fine on wireless so I didn't discover this issue until connecting the ethernet cable. The adapter would show up as eth1 and get dhcp address as usual, but wouldn't actually connect to anything. No ping reply, no local net, no internet, no nothing. But the usb wireless plug still worked perfectly. The log files and dmesg showed that network adapter was starting and stopping continuously until finaly shutting down. Tried everything, but to no avail.

The solution:
After reading this thread I localised the /etc/udev/rules.d/70-persistent-net.rules file.
And there it was: An entry showing data and mac address for the old Via network adapter on the old mainboard. Replaced the mac address with the new Realtek one and rebooted, but still no luck. Deleteded 70-presistent-net.rules, rebooted again and everything came back to life

So thank you for leading me to the solution!