VMWare network interface name change with wily → xenial upgrade

[Herb McNew]

Hi,

I just (2016-02-26) upgraded from wily to xenial in my VMWare VM. The network interface name changed but the upgrade process didn't change /etc/network/interfaces. As such I was left without networking. This may be related to bug #1473542, but obviously isn't the same.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: udev 229-1ubuntu4
ProcVersionSignature: Ubuntu 4.4.0-7.22-generic 4.4.2
Uname: Linux 4.4.0-7-generic x86_64
ApportVersion: 2.20-0ubuntu3
Architecture: amd64
Date: Fri Feb 26 16:54:47 2016
InstallationDate: Installed on 2015-10-29 (120 days ago)
InstallationMedia: Ubuntu-Server 15.10 "Wily Werewolf" - Release amd64 (20151021)
Lsusb:
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
 Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: VMware, Inc. VMware Virtual Platform
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-7-generic root=UUID=9b4f66d9-95e1-45ff-b167-8ce887475c7e ro elevator=noop
SourcePackage: systemd
UpgradeStatus: Upgraded to xenial on 2016-02-26 (0 days ago)
dmi.bios.date: 07/02/2015
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: 6.00
dmi.board.name: 440BX Desktop Reference Platform
dmi.board.vendor: Intel Corporation
dmi.board.version: None
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 1
dmi.chassis.vendor: No Enclosure
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd07/02/2015:svnVMware,Inc.:pnVMwareVirtualPlatform:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:
dmi.product.name: VMware Virtual Platform
dmi.product.version: None
dmi.sys.vendor: VMware, Inc.

[Martin Pitt (pitti)]

Can you please check if you have an /etc/udev/rules.d/70-persistent-net.rules?

According to your UdevDb.txt you use the standard e1000e controller. I suppose what happened is that the old persistent-net-generator ignored VMWare devices, but ifnames knows about them. So we need a similar trick to what we do for virtio ethernet devices in udev.postinst.

[Martin Pitt (pitti)]

Note to myself: We already have this logic for upgrading virtualized hosts:

  # we enabled net.ifnames in 220-7 by default; don't change iface names in
  # virtualized envs (where 75-persistent-net-generator.rules didn't work)
  if dpkg --compare-versions "$2" lt-nl "220-7~" &&
     [ ! -e /etc/udev/rules.d/70-persistent-net.rules ] &&
     [ ! -e /etc/udev/rules.d/80-net-setup-link.rules ] &&
     ! grep -q net.ifnames /proc/cmdline ; then
    mkdir -p /etc/udev/rules.d
    cat <<EOF > /etc/udev/rules.d/80-net-setup-link.rules
# This machine is most likely a virtualized guest, where the old persistent
# network interface mechanism (75-persistent-net-generator.rules) did not work.
# This file disables /lib/udev/rules.d/80-net-setup-link.rules to avoid
# changing network interface names on upgrade. Please read
# /usr/share/doc/udev/README.Debian.gz about how to migrate to the currently
# supported mechanism.
EOF
  fi

We enabled ifnames in 220-7. But apparently VMWare devices naming changed after wily's 225.

[Herb McNew (herb)]

Hi,

I don't have anything in /etc/udev/rules.d

# ls -al /etc/udev/rules.d/
total 8
drwxr-xr-x 2 root root 4096 Oct 15 08:01 .
drwxr-xr-x 4 root root 4096 Feb 26 02:54 ..

[Haw Loeung (hloeung)]

| [ 1.939106] e1000 0000:02:00.0 ens32: renamed from eth0

That would be because udev v197 and above now uses predictable network interface names by default[1]. The upgrade process should probably add net.ifnames=0 on the kernel command lin or update /e/n/i.

[1]http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

[Martin Pitt (pitti)]

@Haw: see comment #3.

[Martin Pitt (pitti)]

I installed VMWare player and compared a wily and a xenial installation. On xenial I indeed get "ens33", while on wily I get a rather bad name "eno16777736". You did not mention the old name of the ethernet interface, but can you confirm that this was a wily *install* (as opposed to an upgrade from an earlier release), and that the old name was *not* eth0, but "eno16777736" or similar? Then indeed the migration to ifnames does not apply as wily already used ifnames.

This naming was fixed in https://github.com/systemd/systemd/commit/6c1e69f9 by ignoring interface indexes that the BIOS reported that are implausibly high (as VMWare does that for some reason).

We do know the slot-based names that are being used since the above commit so we could attempt to auto-fix at least /etc/network/interfaces in postinst. However, we can't fix possible other places where the previous name is being used, so perhaps the safest approach would be to document this in the release notes and in NEWS.

[Martin Pitt (pitti)]

I added some migration postinst code: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu&id=e4cad

[Herb McNew (herb)]

The old name was eno16777728 and it was a wily install, not upgraded from a previous release.

[Simon Déziel (sdeziel)]

@pitti, this new code [*] causes the postinst to fail when no eno* device exist:

  /var/lib/dpkg/info/udev.postinst: 109: [: Illegal number: *

*: https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu&id=47584521cd23ab3490b40b8d95a1748d86ad7f25

[Martin Pitt (pitti)]

@Simon: This is tracked in bug 1560112

[Martin Pitt (pitti)]

@Simon: The postinst certainly writes that error message, but it does not actually fail, right?

[Simon Déziel (sdeziel)]

@Martin, correct, the postinst succeeds, sorry for the confusion.

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 229-3ubuntu1

---------------
systemd (229-3ubuntu1) xenial; urgency=medium

  * Merge with Debian unstable. Remaining Ubuntu changes:
    - Hack to support system-image read-only /etc, and modify files in
      /etc/writable/ instead.

    Upgrade fixes, keep until 16.04 LTS release:
    - systemd Conflicts/Replaces/Provides systemd-services.
    - Remove obsolete systemd-logind upstart job.
    - Clean up obsolete /etc/udev/rules.d/README.
    - systemd.postinst: Migrate mountall specific fstab options to standard
      util-linux "nofail" option.
    - systemctl: Don't forward telinit u to upstart. This works around
      upstart's Restart() always reexec'ing /sbin/init on Restart(), even if
      that changes to point to systemd during the upgrade. This avoids running
      systemd during a dist-upgrade. (LP: #1430479)
    - Provide shutdown fallback for upstart. (LP: #1370329)
    - Break lvm (<< 2.02.133-1ubuntu1) and remove our dummy /etc/init.d/lvm2
      on upgrades, as it's shipped by lvm2 now.
    - Make udev break on mdadm << 3.3-2ubuntu3, as udev's init script dropped
      the "Provides: raid-mdadm".
    - Clean up /var/log/udev on upgrade (which is written under upstart, but
      not under systemd). (LP: #1537211)
    - Migrate existing s390x network configuration to new names. (LP: #1526808)
    - systemd.postinst: Bump Version comparison for migrating the UTC setting
      from /etc/default/rcS to /etc/adjtime, to run it for upgrades to 16.04.
    - VMWare BIOS reports implausibly high onboard numbers. This got fixed in
      upstream commit 6c1e69f9. Migrate names in ifupdown accordingly.
      (LP: #1550539)

systemd (229-3) unstable; urgency=medium

  [ Martin Pitt ]
  * debian/tests/timedated: Add tests for "timedatectl set-local-rtc".
  * Be more tolerant in parsing /etc/adjtime.
  * debian/systemd.postinst: Don't fail package installation if systemctl
    daemon-reload trigger fails. This does not fix the root cause of the
    reload failures, but at least causes fewer packages to be in a broken
    state after upgrade, so that a reboot or apt-get -f install have a much
    higher chance in succeeding. (For bugs like LP #1502097 or LP #1447654)
  * debian/tests/networkd: Skip test_hogplug_dhcp_ip6 when running against
    upstream as well.
  * debian/tests/boot-and-services: Wait for units to stop with a "systemctl
    is-active" loop instead of static sleeps.
  * debian/tests/networkd: Skip DHCPv6 tests for downstream packages too. This
    is an actual regression in networkd-229, to be investigated. But this
    shouldn't hold up reverse dependencies.
  * Fix assertion in add_random(). (LP: #1554861)
  * debian/tests/boot-and-services: Don't assert on "Stopped Container c1"
    message in NspawnTests.test_service(), this is sometimes not present. Just
    check that the unit did not fail.
  * Add "adduser" dependency to systemd-coredump, to quiesce lintian.
  * Bump Standards-Version to 3.9.7 (no changes necessary).
  * Fix timespec parsing by correctly initializing microseconds.
    (Closes: #818698, LP: #1559038)
  * networkd: Add fallback if FIONREAD is not supported. (C...

[Amos Hayes (ahayes-polkaroo)]

I just encountered this bug today when upgrading from a fully updated 14.04 server to 16.04 using do-release-upgrade. My static IP configured in /etc/network/interfaces was configured to come up on eth0. Logging in on the console and replacing eth0 with ens32 in that interfaces file and rebooting fixed things.