Recently I’ve swapped the mainboard in my file server. The old board was an Asus F1A75, the “new” board is the Asus F1A75-M. The former uses an RTL8111E NIC, while the new board has an Atheros NIC. The problem now is that on boot, the NIC doesn’t activate as the kernel reports it can’t find the device eth0 (the onboard NIC). I’ve manually updated the /etc/network/interfaces file to include an eth1 stance and I’m able to activate it with ifup eth1. So, clearly the kernel knows about the Atheros NIC and has the kernel module for it at the ready, but it’s apparently not loaded and/or correctly assigned. The main issue is mostly that it doesn’t survive a reboot, for some unknown reason.
So, any suggestions on fixing this or am I looking at a re-install on the new mainboard? (the system has a separate OS disk, which is an SSD so while not preferred nor ideal, is manageable time-wise)
Kernel can enumerate pci devices and read basic information about devices from the base address registers without having a driver loaded even.
Normally, udev would load the correct module based on /lib/modules/<version>/modules.alias .
If your atheros driver is not mentioned there, or if it’s built using a different way and doesn’t come with the kernel, it won’t be loaded using that mechanism and you’d have to load it another way. (e.g. deal with modules.conf or modules.load.d)
Once you setup the driver to be always loaded , you should also make sure the network interface has a correct name in your configs , ideally something that doesn’t randomly change on every boot: NetworkInterfaceNames - Debian Wiki
By which I mean, does the system see the device, but fail to configure it; or does the system not even recognise the PCI device as a NIC… then I read post 3/reply 2…
It appears the modules.alias file has no reference to Atheros or AR8151. (yes, I did use lower case )
For reference, the interfaces file contains the following: allow-hotplug eth0 \ iface eth0 inet static \ address 192.168.1.10 \ netmask 255.255.255.0 \ network 192.168.1.0 \ gateway 192.168.1.1 \ iface eth1 inet dhcp
Formatting goes a bit haywire here, but it’s fine in the actual file.
For clarity, the NIC now uses eth1, whereas it should use eth0. Eth1 is now up, so the kernel knows about it and has a driver to use it. Or does it use a generic driver for stuff it has no dedicated driver for?
I installed the firmware-atheros package, but apparently that’s only for wireless NIC’s. I’m considering purging the Realtek network related packages, but that poses a risk of disabling the NIC outright.
Thanks so far for the help folks, much appreciated!
I dont think you need to purge any of the Realtek stuff. I am still trying to find the right combo of search terms to see if anyone else has similar issues.
lspci -vv | grep -i net
will give you Very Verbose, which might provide more detail.
Unfortunately, it didn’t add anything new. I’m inclined to just do a re-install. Although that may wait until the weekend, perhaps someone comes up with the magic oneliner
I had a look at that .rules file and it might very well be the root cause of the issue. I’ll investigate further and do some experimenting to see if it solves the problem.
That can wreck your udev rules if there are any other files with persist in the name.
I recommend to just edit the /etc/udev/rules.d/{somenumber}-persistent-net.rules and clean the existing rules or edit the NAME parameter of the network cards.
Right, that was an “easy” fix! I moved /etc/udev/rules.d/70-persitent-net.rules out of the way (just renamed it with .bak at the end), commented out the eth1 stance in /etc/network/interfaces and rebooted. And a short time later, I was able to log in, both via ssh as well as the Webmin interface, so obviously it works. A quick look in /etc/udev/rules.d revealed: nothing. Only the persistent-net file I had renamed. I’ll leave it for now, well under 512 bytes so very, very little space gained if removed
Thanks to anyone who contributed, much appreciated!
)