some 4 weeks ago I sent a first proposal to change persistent network
interface naming away from our current
/lib/udev/rules.d/75-persistent-net-generator.rules (which is
inherently racy and doesn't apply to all virtualized environments) to
Based on the comments and followups (mostly on the Debian ML) I
updated the proposal.
Martin Pitt [2015-05-08 7:59 +0200]:
> Details about [ifnames]
> This is a generic solution which extends the [biosdevname] idea and
> thus applies to all practical cases and all architectures. It doesn't
> need any persistant state (i. e. dynamic /etc/udev/rules.d/) and thus
> applies nicely to snappy/touch, and also avoids the race condition.
> The main downside is that by nature the device names are not familiar
> to current admins yet. For BIOS provided names you get e. g. ens0, for
> PCI slot names enp1s1 (ethernet) or wlp3s0 (wlan). But that's a
> necessary price to pay (biosdevname names look similar).
The main objection in the discussion was that path based names aren't
appropriate for USB based devices. I agree, so I change my proposal to
use MAC based names for anything USB based. The names will look even
worse as they include the MAC in hex (enx112233445566), but the two
goals "use MAC for these devices", "don't maintain state files in
/etc", and "avoid any collisions" don't leave room for much else.
However, on a desktop you don't ever care about the device names, and
higher-level firewall tools will also hide this. After all, we
survived the step from /dev/sda1 to UUID=112233DEADBEEF... as well :-)
> I propose to retire [mac], i. e. drop
> /lib/udev/rules.d/75-persistent-net-generator.rules and enable
> [ifnames] by default.
... and ship a naming policy by default which uses MAC based names
FYI, this will look like
| $ cat /lib/systemd/network/01-mac-for-usb.link
| NamePolicy=kernel database mac onboard slot path
It's easy enough to override/customize, see man systemd.link. (Despite
the name, this is all udev; it doesn't depend on using systemd or
networkd). This will of course also be included in the documentation.
> For upgrades: As we don't know what refers to existing stable network
> names, we can't ever safely remove a generated
> /etc/udev/rules.d/70-persistent-net.rules. So when we do the above,
> names on existing installations will *not* change (as
> 70-persistent-net.rules trumps [ifnames]).
> So we can only let time and replacing/reinstalling machines take care
> of this.
Michael Biebl and I discussed that the other day. We plan to do that
15.10 (Ubuntu) / stretch (Debian)
- Enable ifnames for new installations
- Drop [mac] generator
- Point out the transition/documentation in NEWS
- Ship example rules to show how to use your own custom names
Ubuntu 16.10 (after next LTS) / stretch+1 (or maybe +2) (Debian)
- Check existance/non-emptiness of
/etc/udev/rules.d/70-persistent-net.rules in udev.preinst,
Show critical debconf note, and refuse to upgrade
- Drop our hack to retry renames for a while (to mitigate the race)
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Martin Pitt [2015-05-08 7:27 +0200]: