in General

This is progress? (iftab vs. udev)

Apparently, the delightfully simple /etc/iftab is no longer used, replaced with the ugly and fiercely undelightful /etc/udev/rules.d/70-persistent-net.rules. See, you can even tell from the name of the file that you’re not going to like it.

Surely udev could read and do something useful with /etc/iftab, even if it only provides a fraction of the functionality? Ubuntu successfully migrates the configuration, which is plenty good, but… ew.

I’d kick myself for becoming a “this is progress?! in my day…” curmudgeon, but this is a matter of protecting simplicity rather than pointless defense of “the old ways”. :-)

Here’s /etc/iftab:

# This file assigns persistent names to network interfaces.
# See iftab(5) for syntax.

eth0 mac 00:15:c5:4a:71:98 arp 1
eth1 mac 00:18:de:03:3e:0d arp 1

While this is /etc/udev/rules.d/70-persistent-net.rules:

# This file maintains persistent names for network interfaces.
# See udev(7) for syntax.
# Entries are automatically added by the 75-persistent-net-generator.rules
# file; however you are also free to add your own entries.

# PCI device 0x14e4:0x1600 (tg3)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:15:c5:4a:71:98", ATTR{type}=="1", NAME="eth0"

# PCI device 0x8086:0x4222 (ipw3945)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:18:de:03:3e:0d", ATTR{type}=="1", NAME="eth1"

Write a Comment


Comments will be sent to the moderation queue.


  1. Not sure I see what the issue is? The two files contain basically the same information – udev syntax is a little more verbose, but I also think it’s more readable because of that, compared to the terse iftab format.

  2. Those were my thoughts when I noticed it. But, udev enables one nice thing; separation of interfaces by driver, which wasn’t possible with iftab. There are also other possibilities…
    But yes, looks strange and requires some adoption :)

  3. Afaik udev files are only read by the userland daemon (udevd), ….i’m surprised they didn’t just go with XML and be done with it rather than invent yet another ugly format that takes up too many terminal columns.

  4. Besides being somewhat more verbose, I can’t see why the udev one is worse then the iftab one. I guess you could even remove the “DRIVER=”*”” thingie if you like it shorter :-).

    I hate having to pull up the crontab or iftab man pages just to know the format of the entries.

  5. udev rules give you more options, but if you reduce it to the bare minimum, the following should do:

    Now, this is not THAT different from iftab, is it?

  6. The udev rules are bit more verbose, but are much more flexible; we couldn’t deal with PS3 network devices with iftab because they all have the same MAC address, but that is possible with udev.

    In practice, you rarely add lines to these files by hand (its discourage) and only ever really delete one if you’re really OCD and have to have your devices named eth0 and eth1, even after you change your hardware ;)

  7. The good thing about udev is that it writes those rules automatically for you the first time it sees a network device. Also, if it renames a device it logs that to the kernel logs.

    The strange syntax for this file is the normal udev syntax. You can argue it is *good* that they made this file the same format as their other rules files instead of keeping the old format for /etc/iftab around, which is far less powerful and is just yet another format that would have kept around. Believe it or not, but having this file in normal udev format works against the balkanization of of file formats.

  8. Meh. I don’t see it. The udev entry is definitely a little uglier, but contains basically the same info.

    There is one way in which these udev rules are vastly inferior, though: if you were starting from absolutely nothing, it would be a lot harder to get what you needed for a udev rule than for an iftab one. Partly it’s a syntax thing, but mostly it’s because that udev covers a much larger swath than iftab. You could probably get a good idea of exactly what you needed by reading the iftab(5) manpage. You probably wouldn’t even get close with the udev(7) page.

  9. The difference is that the file is in a *completely* nonobvious location for somebody who has been a Linux veteran and used to the /etc/iftab file for years.

    iftab doesn’t seen to make any mention that it’s deprecated or one should see the latter udev file either.

  10. @Scott James Remnant: Not possible to build udev rules out of /etc/iftab at runtime?

    @Joe Shaw: Yeah, that is pretty sucky, and a fairly good reason to consider keeping mildly more human-grokkable files as ‘frontend’ configuration to udev rules.

  11. Uhm. Is this a trick? I mean, why is the interface name _interesting_ and why do you _care_? The interface name is a freaking cookie and that’s it.

    I mean, I’d understand if you are building some kind of 24/7 server with failover, bonding support etc. then you might need to run scripts in userland that needs a stable reference to a device.

    Me? For things like laptops or desktops I stopped caring about things like network interface names ever since NetworkManager grew VPN support. So it’s just been clickity-click for me since. With the occasional whining to Dan Williams’s mom about Dan breaking NetworkManager of course ;-)

    Of course I’m setting myself up to be flamed here.

  12. @davidz: For the particular use case through which I discovered this change, I don’t care about the name, nor find it interesting. But it needs to be consistent.

    I realised a couple of weeks ago that it has been a very long time indeed since I last edited /etc/network/interfaces on any machine (thanks to dhcp everywhere and/or NetworkManager on desktops/laptops. :-)

  13. I totally agree. I got hit by this change just the other day. I find it really irritating when important functional aspects of the system are silently changed. It leaves me scratching my head and looking foolish while I try to find a resolution to aproblem I _used_ to know how to handle. I don’t agree that replacing a well understood and readable config file with less accessible one if a good thing, but if it must change, AT LEAST LET US KNOW THAT IT HAS CHANGED! Put it in detailed release notes, _something_!Leaving people to discover things like this while in the thick of it is just rude.

  14. I think you *could* just add a shell script that reads iftab and gets called from udev.
    But one of the design goals of udev is to avoid shell scripts in as many as possible cases for speed reasons. The old hotplug system is said to have wasted tons of time while booting by doing things with bash.

    I don’t really understand the whole udev bashing thing. I think udev is nicely flexible and only has minimal policy in the c code. It’s basicly a big matching and dispatch engine. And still flexible because you can call out to programs when really needed. But is it worth to introduce a helper to read iftab and include iftab and the helper into the initramfs too? more places for things that need to go into initramfs isn’t so great for usability either, is it?

  15. Today I cloned a basic installation of debian using rsync onto another server. After rebooting, the initscripts told me that eth0 and eth1 were not present. Instead, my interfaces were named eth2 and eth3, because eth0 and eth1 were already taken by the dynamic generated udev rules.

  16. Uh, I remember ages ago I had a gentoo box I used as router, and not having mappings sucked.
    So I dived into udev and came up with something that looks a lot like those new rules.
    Even if it is ugly, it’s better because udev can then be used to have all sorts of nice stuff, like permanent mappings of SCSI disks (by default, gentoo used to call the first “alive” disk /dev/sda, hence fucking up the fstab in case the first disk died), and this way you learn udev syntax.
    Unified is better.

  17. Reminds me of my favourite comment from a /etc file, also about needless complexity (SysV-ness in this case, from stock /etc/init.d/inetsvc on some version or other of Solaris):

    # Run inetd in “standalone” mode (-s flag) so that it doesn’t have
    # to submit to the will of SAF. Why did we ever let them change inetd?