After I imaged the disks from a failing Debian server to newer hardware, I got the error message ifdown: Interface eth0 not configured after issuing the command ifdown eth0. There’s not a lot of documentation out there about this so hopefully this writeup will help you if you’re getting this puzzling message.
This should be the same in Ubuntu, for what it’s worth.
ifdown: Interface eth0 not configured
The machine booted without much in the way of error messages or complaints. That didn’t surprise me; I’ve even moved hardware from one generation of Intel to another generation of AMD or the other way around and gotten away with it. What puzzled me, though, was that there was absolutely no sign of eth0 or eth1. And the computer wasn’t responding on its static IP address.
I’ll step through what I did, just in case it gives you a quick fix.
ifdown eth0
Normally what you do when networking acts up is bounce the network interface. Issuing the trusty command ifdown eth0 gave me the puzzling error message of ifdown: interface eth0 not configured.
ifconfig eth0
But it was configured. It was right there in /etc/network/interfaces where it’s supposed to be. My other go-to, ifconfig eth0, was no help either. It gave me an error message error fetching interface information: Device not found.
/etc/network/interfaces
I pulled up /etc/network/interfaces again and scrolled down. I found the iface eth0 inet static line. It looked good. I double checked the syntax of the lines underneath it. Those all looked good. For grins, I even backed up the file and changed eth0’s configuration to DHCP, then tried to run ifdown eth0 followed by ifup eth0 again. That didn’t change anything. Changing the file back and bouncing the interfaces again didn’t help either, but it did set me up for success once I found my answer.
Checking the physical hardware
It’s always a good idea to check the physical hardware just to be on the safe side. The cards were connected and I saw link lights. The lights on the switch side looked good too. The cards were connecting at full speed. So that meant the operating system just couldn’t figure out what to do with them.
A hardware issue seemed like a bit of a long shot, because normally a hardware issue will give different error messages than this. But it only takes a couple of minutes to check.
Searching online
Normally it helps to search online. Usually someone else has had the problem before and found an answer. But in this case, searching online wasn’t a lot of help. Searching on ifdown: interface eth0 not configured turns up plenty of discussion but not a lot of answers. Mostly I found people rage quitting and changing to another distribution, or to FreeBSD, out of frustration. I’m sure that worked. Then again, reinstalling what I had would also work. But I didn’t want to lose the applications I was running.
Besides, once you find the problem it doesn’t take long to fix. One of my coworkers used to like to tease me by saying I treated our Linux systems like Windows boxes. Reinstalling the whole operating system to fix a network issue really feels like treating it like a Windows box.
Digging into kernel modules
Since I couldn’t find the silver bullet online, I decided it was time to dive into the relevant kernel modules. If you’re not super familiar with Linux, network drivers take the form of kernel modules, and you can load and unload them to get an idea of what’s going on.
This system had Broadcom NICs in it, so the kernel module was bnx2. If it had an Intel NIC, I’d probably have to mess with the e1000e module. Another common module is rtl8169, for cheap Realtek NICs. If you’re unsure what your system has, you can find some clues in the file /etc/udev/rules.d/70-persistent-net.rules, but I’m getting ahead of myself.
After messing around entirely too long, it occurred to me to issue these commands to see what was going on:
rmmod bnx2
modprobe bnx2
tail /var/log/kernel.log
And that told me something called udev was renaming eth0 to eth10. That was nice of it. But it wasn’t what I wanted. I wanted the network card to be eth0, not something unconfigured called eth10.
Brute forcing it
If you’re not certain what kind of network cards you have, the command lspci should give you some clues. Look for the usual suspects like Intel, Broadcom, and Realtek. Then just run rmmod [module] followed by modprobe [module], subbing in e1000e, rtl8169, and bnx2 for [module] until you find a module that responds. You’ll need to know the correct kernel module for the next step, unless you want to fumble around a bit.
Changing the network card mapping
That pesky udev keeps its rules in /etc/udev/rules.d/ where I found a file called 70-persistent-net.rules. That file was a listing of the old system’s NICs and my new system’s NICs.
I found the old eth0 and eth1 on the first two lines of the file. I found my new eth10 and eth11 on the last two lines. The lines all look something like this:
# PCI device 0x14e4:0x1659 (bnx2)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="13:37:13:37:13:37", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
The string “13:37:13:37:13:37” is the MAC address of the NIC. I wish that was my real MAC address. The PCI device line helps you figure out what card it is, especially if you have multiple cards in play. Note the name of the kernel module in parenthesis.
The easiest thing to do is to back up the file, then edit it. Delete all of the old lines referencing the old network cards altogether. Then find your current card(s), decide which one you want to be eth0 and eth1 and change the lines. Then save the file.
If you’re not certain which one your current cards are, it’s most likely the card or cards at the end of the file, so you can start with those.
Finishing up
Editing my file and cleaning it up didn’t take long. Then I ran these commands again:
rmmod bnx2
modprobe bnx2
tail /var/log/kernel.log
At that point, kernel.log suggested I had eth0 again. So I ran the commands ifdown eth0 and ifup eth0 and indeed I did. No error messages this time. I could even ping Google. And ifconfig eth0 confirmed I had the right static IP address. I repeated those commands for eth1 and those turned out fine too.
So then I tested my application, which was hard-coded for eth0 and eth1 and the static IP addresses all over the place. It all worked too. I was happy, and more importantly, my boss was happy.
So, fixing networking after moving Debian to new hardware isn’t all that hard once you know what files you have to look into. And that mysterious error message ifdown: interface eth0 not configured isn’t so unhelpful after all. It’s mostly a matter of knowing what to do with that information. I hope I’ve made it easier for you.