Is it possible to turn this off, revert to (non persistent) eth0, eth1,
The place where I've gotten stuck with this is when PXE booting with a
rootfs exported over NFS.
In this case you need to specify, eg, DEVICE=eth0, in your
initramfs.conf when building the initrd image that you're going PXE boot
with. But this is very problematic unless you can easily know in advance
what the name of the first NIC will be, unless it will be the same NIC
name across a range of arbitrary hardware.
My use case is the System76 imaging system (Tribble). We PXE boot into
(basically) a vanilla Ubuntu server with a read-only rootfs exported
over NFS, which then launches the imaging application.
Because we've needed to count on the first NIC being named eth0, we've
always removed the biosdevname package when building this server
But I'm not sure how to work around this with this new naming scheme.
Any advice would be much appreciated!
I'm also curious how MAAS is dealing with this, as I believe its
ephemeral environment has similar requirements.
On 06/03/2015 04:15 AM, Martin Pitt wrote:
> Hello all,
> 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
> udev's "net.ifnames":
> 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
> for USB.
> FYI, this will look like
> | $ cat /lib/systemd/network/01-mac-for-usb.link
> | [Match]
> | Path=*-usb-*
> | [Link]
> | NamePolicy=kernel database mac onboard slot path
> | MACAddressPolicy=persistent
> 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
> in steps:
> 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)
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel