/etc/iftab not updated after hardware change

Bug #102336 reported by iGadget
4
Affects Status Importance Assigned to Milestone
udev (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

On Feisty Beta (upgraded from Herd 5), when changing hardware (in my case, I had to replace the motherboard with 2 onboard NICs, luckily I could replace it with the same model), /etc/iftab is not updated. So the MAC adresses from the NICs on the old mainboard still exist in iftab, preventing the NICs on the new mainboard from getting assigned to eth0 and eth1. Instead, they are assigned eth2 and eth3, in random order at every boot (which is, IMHO, yet another bug).

I had to manually edit /etc/iftab and replace the old MAC adresses with the new ones to fix this problem (actually, I'm assuming this is the solution, I'll know for sure once I reboot the system). I only knew this after reading about bug #49121.

IMHO, when any NIC which has a MAC adress in iftab, is no longer present in the system at boot, it should be removed or commented out from /etc/iftab. If the system is 'confused' whether the new NIC(s) should be assigned eth0, eth1 or whatever, a warning should be displayed or a dialog should show up, allowing the user to rectify the situation.

My system specs:
-MSI K8N mainboard
-Nvidia CK8S NIC (onboard), eth0
-Realtek RTL-8169 NIC (onboard), eth1
-Ubuntu Feisty Beta

If more info is needed, let me know.

ProblemType: Bug
Architecture: i386
Date: Tue Apr 3 14:04:18 2007
DistroRelease: Ubuntu 7.04
Uname: Linux simba 2.6.20-13-generic #2 SMP Sun Mar 25 00:21:25 UTC 2007 i686 GNU/Linux

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

For feisty+1 we plan to switch to using the static device name rules file, rather than iftab.

The correct behaviour would be that your two new cards get eth2 and eth3, but don't randomly swap (since eth0 and eth1 were "taken" by your previous cards).

We can't steal those names back, because we have no way of knowing whether or not the device should be "present" -- they may be removable cards that you intend to reactivate later. The easiest solution is to give them new names, and require new configuration (a worst case would be a firewall/server where the machine randomly renumbered everything after a hardware change and got all the rules wrong)

Changed in udev:
importance: Undecided → Low
status: Unconfirmed → Confirmed
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

We have switched to the persistent net naming rules; which are updated on each hardware change

Changed in udev:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.