Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Jessie to Stretch Upgrade: Enable Predictable Network Interface Names
253 views
Skip to first unread message
debian...@patschie.de
Jul 27, 2017, 11:30:06 AM7/27/17
to
Hi,
I’m running into some troubles to enable the predictable network interface names for a system upgraded from Jessie.
What I figured out so far:
Setting net.ifnames=1 on the kernel command line doesn’t help and seems no longer to be supported parameter (at least "sysctl - a" doesn’t show it).
Removing any /etc/udev/rules.d/ file handling the network interface doesn’t bring the desired effect of having predictable network interface names.
I started now to compare /lib/udev/rules.d from a clean stretch installation with the files on a upgraded system, the clean installation has much more files.
So next try reinstalling udev to get all missing/new rule files from stretch, but that didn’t work either.
Any ideas what I could try next or missed to check?
Thanks a lot.
Patrick
I’m running into some troubles to enable the predictable network interface names for a system upgraded from Jessie.
What I figured out so far:
Setting net.ifnames=1 on the kernel command line doesn’t help and seems no longer to be supported parameter (at least "sysctl - a" doesn’t show it).
Removing any /etc/udev/rules.d/ file handling the network interface doesn’t bring the desired effect of having predictable network interface names.
I started now to compare /lib/udev/rules.d from a clean stretch installation with the files on a upgraded system, the clean installation has much more files.
So next try reinstalling udev to get all missing/new rule files from stretch, but that didn’t work either.
Any ideas what I could try next or missed to check?
Thanks a lot.
Patrick
Michael Biebl
Jul 27, 2017, 12:00:06 PM7/27/17
to
Hi Patrick
Am 27.07.2017 um 17:15 schrieb debian...@patschie.de:
> Hi,
>
> I’m running into some troubles to enable the predictable network interface names for a system upgraded from Jessie.
>
> What I figured out so far:
> Setting net.ifnames=1 on the kernel command line doesn’t help and seems no longer to be supported parameter (at least "sysctl - a" doesn’t show it).
Setting that parameter should work, but it doesn't take precedence over
an existing /etc/udev/rules.d/70-persistent-net.rules
Since net.ifnames=1 is the default since stretch, you don't need to set
it explicitly though.
> Removing any /etc/udev/rules.d/ file handling the network interface doesn’t bring the desired effect of having predictable network interface names.
>
> I started now to compare /lib/udev/rules.d from a clean stretch installation with the files on a upgraded system, the clean installation has much more files.
> So next try reinstalling udev to get all missing/new rule files from stretch, but that didn’t work either.
>
> Any ideas what I could try next or missed to check?
>
Most likely the file /etc/udev/rules.d/70-persistent-net.rules got
embedded in the initramfs. So once you removed that file, you also need
to rebuild the initramfs via update-initramfs -u
Michael
Am 27.07.2017 um 17:15 schrieb debian...@patschie.de:
> Hi,
>
> I’m running into some troubles to enable the predictable network interface names for a system upgraded from Jessie.
>
> What I figured out so far:
> Setting net.ifnames=1 on the kernel command line doesn’t help and seems no longer to be supported parameter (at least "sysctl - a" doesn’t show it).
an existing /etc/udev/rules.d/70-persistent-net.rules
Since net.ifnames=1 is the default since stretch, you don't need to set
it explicitly though.
> Removing any /etc/udev/rules.d/ file handling the network interface doesn’t bring the desired effect of having predictable network interface names.
>
> I started now to compare /lib/udev/rules.d from a clean stretch installation with the files on a upgraded system, the clean installation has much more files.
> So next try reinstalling udev to get all missing/new rule files from stretch, but that didn’t work either.
>
> Any ideas what I could try next or missed to check?
>
embedded in the initramfs. So once you removed that file, you also need
to rebuild the initramfs via update-initramfs -u
Michael
debian...@patschie.de
Jul 27, 2017, 12:10:06 PM7/27/17
to
Hi Michael,
I forgot to mention that I also recreated the initramfs:
after several tries just to update it, I deleted the initramfs and recreated it completely.
But still the same effect.
Is there a way to manually check the contents of the initramfs, just to make sure that the 70-persistent-net.rules isn’t there?
Patrick
I forgot to mention that I also recreated the initramfs:
after several tries just to update it, I deleted the initramfs and recreated it completely.
But still the same effect.
Is there a way to manually check the contents of the initramfs, just to make sure that the 70-persistent-net.rules isn’t there?
Patrick
Greg Wooledge
Jul 27, 2017, 12:20:08 PM7/27/17
to
On Thu, Jul 27, 2017 at 06:04:49PM +0200, debian...@patschie.de wrote:
> Is there a way to manually check the contents of the initramfs, just to make sure that the 70-persistent-net.rules isn’t there?
mkdir /tmp/foo &&
> Is there a way to manually check the contents of the initramfs, just to make sure that the 70-persistent-net.rules isn’t there?
cd /tmp/foo &&
unmkinitramfs /boot/initrd.whatever
(The old way of just running cpio won't work any more, because the new
initrd.img files are a concatenation of multiple cpio archives.)
Michael Biebl
Jul 27, 2017, 12:30:07 PM7/27/17
to
Am 27.07.2017 um 18:04 schrieb debian...@patschie.de:
> Hi Michael,
>
> I forgot to mention that I also recreated the initramfs:
> after several tries just to update it, I deleted the initramfs and recreated it completely.
> But still the same effect.
>
> Is there a way to manually check the contents of the initramfs, just to make sure that the 70-persistent-net.rules isn’t there?
lsinitramfs /boot/initrd.img-$(uname -r) | grep 70-persistent-net.rules
> Hi Michael,
>
> I forgot to mention that I also recreated the initramfs:
> after several tries just to update it, I deleted the initramfs and recreated it completely.
> But still the same effect.
>
> Is there a way to manually check the contents of the initramfs, just to make sure that the 70-persistent-net.rules isn’t there?
This should come up empty.
The new naming is setup via /lib/udev/rules.d/80-net-setup-link.rules
and a link file called 99-default.link
lsinitramfs /boot/initrd.img-$(uname -r) | grep 80-net-setup-link.rules
lib/udev/rules.d/80-net-setup-link.rules
lsinitramfs /boot/initrd.img-$(uname -r) | grep 99-default.link
lib/systemd/network/99-default.link
Is this a bare metal or a VM?
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Patrick Flaig
Jul 27, 2017, 12:50:06 PM7/27/17
to
> Am 27.07.2017 um 18:25 schrieb Michael Biebl <bi...@debian.org>:
>
> Am 27.07.2017 um 18:04 schrieb debian...@patschie.de:
>> Hi Michael,
>>
>> I forgot to mention that I also recreated the initramfs:
>> after several tries just to update it, I deleted the initramfs and recreated it completely.
>> But still the same effect.
>>
>> Is there a way to manually check the contents of the initramfs, just to make sure that the 70-persistent-net.rules isn’t there?
>
>
> lsinitramfs /boot/initrd.img-$(uname -r) | grep 70-persistent-net.rules
>
> This should come up empty.
>
> The new naming is setup via /lib/udev/rules.d/80-net-setup-link.rules
> and a link file called 99-default.link
99-default.link is missing
> The new naming is setup via /lib/udev/rules.d/80-net-setup-link.rules
> and a link file called 99-default.link
>
> lsinitramfs /boot/initrd.img-$(uname -r) | grep 80-net-setup-link.rules
> lib/udev/rules.d/80-net-setup-link.rules
Available
> lsinitramfs /boot/initrd.img-$(uname -r) | grep 80-net-setup-link.rules
> lib/udev/rules.d/80-net-setup-link.rules
> lsinitramfs /boot/initrd.img-$(uname -r) | grep 99-default.link
> lib/systemd/network/99-default.link
Missing
> lib/systemd/network/99-default.link
>
> Is this a bare metal or a VM?
VirtualBox VM, as well as the Stretch clean install system, where the predictable names are working fine.
> Is this a bare metal or a VM?
Patrick Flaig
Jul 27, 2017, 12:50:06 PM7/27/17
to
Thanks,
confirmed, the initrd doesn’t contain any udev rule files in /etc/udev/rules.d
confirmed, the initrd doesn’t contain any udev rule files in /etc/udev/rules.d
debian...@patschie.de
Jul 27, 2017, 1:00:06 PM7/27/17
to
> Am 27.07.2017 um 18:04 schrieb debian...@patschie.de:
>> Hi Michael,
>>
>> I forgot to mention that I also recreated the initramfs:
>> after several tries just to update it, I deleted the initramfs and recreated it completely.
>> But still the same effect.
>>
>> Is there a way to manually check the contents of the initramfs, just to make sure that the 70-persistent-net.rules isn’t there?
>
>
> lsinitramfs /boot/initrd.img-$(uname -r) | grep 70-persistent-net.rules
>
> This should come up empty.
Confirmed
>> Hi Michael,
>>
>> I forgot to mention that I also recreated the initramfs:
>> after several tries just to update it, I deleted the initramfs and recreated it completely.
>> But still the same effect.
>>
>> Is there a way to manually check the contents of the initramfs, just to make sure that the 70-persistent-net.rules isn’t there?
>
>
> lsinitramfs /boot/initrd.img-$(uname -r) | grep 70-persistent-net.rules
>
> This should come up empty.
>
> The new naming is setup via /lib/udev/rules.d/80-net-setup-link.rules
> and a link file called 99-default.link
99-default.link is missing
> The new naming is setup via /lib/udev/rules.d/80-net-setup-link.rules
> and a link file called 99-default.link
>
> lsinitramfs /boot/initrd.img-$(uname -r) | grep 80-net-setup-link.rules
> lib/udev/rules.d/80-net-setup-link.rules
Available
> lsinitramfs /boot/initrd.img-$(uname -r) | grep 80-net-setup-link.rules
> lib/udev/rules.d/80-net-setup-link.rules
> lsinitramfs /boot/initrd.img-$(uname -r) | grep 99-default.link
> lib/systemd/network/99-default.link
Missing
> lib/systemd/network/99-default.link
>
> Is this a bare metal or a VM?
> Is this a bare metal or a VM?
VirtualBox VM, as well as the Stretch clean install system, where the predictable names are working fine.
Michael Biebl
Jul 27, 2017, 1:30:06 PM7/27/17
to
Am 27.07.2017 um 18:55 schrieb debian...@patschie.de:
>> Am 27.07.2017 um 18:25 schrieb Michael Biebl <bi...@debian.org>:
>> lsinitramfs /boot/initrd.img-$(uname -r) | grep 99-default.link
>> lib/systemd/network/99-default.link
> Missing
Odd. Do you have that file on the host system?
>> Am 27.07.2017 um 18:25 schrieb Michael Biebl <bi...@debian.org>:
>> lsinitramfs /boot/initrd.img-$(uname -r) | grep 99-default.link
>> lib/systemd/network/99-default.link
> Missing
Can you check with debsums -as udev systemd.
/usr/share/initramfs-tools/hooks/udev should copy that link file into
the initramfs.
Do you by chance have any custom initramfs hooks in
/etc/initramfs-tools/hooks which override the udev hook?
Michael Biebl
Jul 27, 2017, 2:00:06 PM7/27/17
to
Am 27.07.2017 um 19:50 schrieb Patrick Flaig:
> Oh my fault, 99-default.link is available, I checked the wrong folder.
> The file is containing some text, saying that the machine is most likely a virtualized guest.
Can you paste the contents verbatim.
> Oh my fault, 99-default.link is available, I checked the wrong folder.
> The file is containing some text, saying that the machine is most likely a virtualized guest.
Can you paste the contents verbatim.
Patrick Flaig
Jul 27, 2017, 2:00:06 PM7/27/17
to
Oh my fault, 99-default.link is available, I checked the wrong folder.
The file is containing some text, saying that the machine is most likely a virtualized guest.
The file is containing some text, saying that the machine is most likely a virtualized guest.
Patrick Flaig
Jul 27, 2017, 2:30:06 PM7/27/17
to
Sure, this is the content:
cat /tmp/foo/lib/systemd/network/99-default.link
# 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/systemd/network/99-default.link 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.
The content of the README, doesn’t help that much as 99-default.link doesn’t seem to be a symlink.
cat /usr/share/doc/udev/README.Debian
This documents udev integration Debian specifics. Please see man udev(7) and
its referenced manpages for general documentation.
Network interface naming
~~~~~~~~~~~~~~~~~~~~~~~~
Since version 197 udev has a builtin persistent name generator which checks
firmware/BIOS provided index numbers or slot names (similar to biosdevname),
falls back to slot names (PCI numbers, etc., in the spirit of
/dev/disks/by-path/), and then optionally falls back to MAC address, and
generates names based on these properties. This provides "location oriented"
names for PCI cards such as "enp0s1" for ethernet, or wlp1s0" for a WIFI card
so that replacing a broken network card does not change the name. As location
based naming does not work well for USB devices, these use a MAC based naming
schema (see /lib/udev/rules.d/73-usb-net-by-mac.rules).
This has been enabled by default since udev 220-7, which affects new
installations/hardware. Existing installations/hardware which already got
covered by the old 75-persistent-net-generator.rules will keep their interface
names, see below.
You can disable these stable names and go back to the kernel-provided ones
(which don't have a stable order) in one of two ways:
- Put "net.ifnames=0" into the kernel command line (e. g. in
/etc/default/grub's GRUB_CMDLINE_LINUX_DEFAULT, then run "update-grub").
- Disable the default *.link rules with
"ln -s /dev/null /etc/systemd/network/99-default.link"
and rebuild the initrd with "update-initramfs -u".
See this page for more information:
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
Legacy persistent network interface naming
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Debian releases up to 8 ("Jessie") and Ubuntu up to 15.04 had an udev rule
/lib/udev/rules.d/75-persistent-net-generator.rules which fixed the name of a
network interface that it got when its MAC address first appeared in a
dynamically created /etc/udev/rules.d/70-persistent-net.rules file.
This had inherent race conditions (which sometimes caused collisions and
interface names like "rename1"), required having to write state into /etc
(which isn't possible for read-only root), and did not work in virtualized
environments.
This old schema is deprecated in Debian 9 ("Stretch"), and will not
be supported any more in Debian 10.
Migration to the current network interface naming
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On package upgrade systems will keep their current names, but they will need to
be manually migrated by Debian 10 / Ubuntu 18.04 LTS. If you rely on the old
names in custom ifupdown stanzas, firewall scripts or other networking
configuration, these need to be updated to the new names.
First, determine all relevant network interface names: those in
/etc/udev/rules.d/70-persistent-net.rules, or if that does not exist (in
virtual machines), in "ip link" or /sys/class/net/.
Then for every interface name use a command like
grep -r eth0 /etc
to find out where it is being used.
Then on "real hardware" machines, rename the file to
70-persistent-net.rules.old; on VMs remove the file
/etc/udev/rules.d/80-net-setup-link.rules instead.
Reboot, adjust configuration files, and test your system.
Custom net interface naming
~~~~~~~~~~~~~~~~~~~~~~~~~~~
In some cases it is convenient to define your own specific names for network
interfaces. These can be customized in two different ways:
* You can create your own names via udev rules, based on arbitrary attribute
and property matches. See man udev(7) for documentation how to write udev
rules. For example, you can create /etc/udev/rules.d/76-netnames.rules with
------------ snip ----------
# identify device by MAC address
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="11:22:aa:bb:cc:33", NAME="eth-dmz"
# identify by vendor/model ID
SUBSYSTEM=="net", ACTION=="add", ENV{ID_VENDOR_ID}=="0x8086", \
ENV{ID_MODEL_ID}=="0x1502", NAME="eth-intel-gb"
# USB device by path
# get ID_PATH if not present yet
ENV{ID_PATH}=="", IMPORT{builtin}="path_id"
SUBSYSTEM=="net", ACTION=="add", ENV{ID_PATH}=="*-usb-0:3:1*", NAME="eth-blue-hub"
------------ snip ----------
The name of the rules file needs to have a prefix smaller than "80" so that
it runs before /lib/udev/rules.d/80-net-setup-link.rules, and should have a
prefix bigger than "75" so that it runs after 75-net-description.rules and
thus you can use matches on ID_VENDOR and similar properties.
* Unless you disabled net.ifnames, you can change the policy
(kernel/bios/path/MAC based naming) in an /etc/systemd/network/*.link file,
for individual devices or entire device classes. See man systemd.link(5) for
details about this. /lib/systemd/network/99-default.link is the default
policy, and /lib/systemd/network/01-mac-for-usb.link makes it use MAC based
names for USB devices.
Any of the above changes require an initrd update with "update-initramfs -u" to
get effective.
Using udev with LDAP or NIS
~~~~~~~~~~~~~~~~~~~~~~~~~~~
If the rules files reference usernames or groups not present in the
/etc/{passwd,group} files and the system is configured to use a
network-based database like LDAP or NIS then udev may fail at boot time
because users and groups are looked up well before the network has been
initialized.
A possible solution is to configure /etc/nsswitch.conf like this:
passwd: files ldap [UNAVAIL=return]
group: files ldap [UNAVAIL=return]
The nsswitch.conf syntax is documented in the glibc manual.
cat /tmp/foo/lib/systemd/network/99-default.link
# 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/systemd/network/99-default.link 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.
The content of the README, doesn’t help that much as 99-default.link doesn’t seem to be a symlink.
cat /usr/share/doc/udev/README.Debian
This documents udev integration Debian specifics. Please see man udev(7) and
its referenced manpages for general documentation.
Network interface naming
~~~~~~~~~~~~~~~~~~~~~~~~
Since version 197 udev has a builtin persistent name generator which checks
firmware/BIOS provided index numbers or slot names (similar to biosdevname),
falls back to slot names (PCI numbers, etc., in the spirit of
/dev/disks/by-path/), and then optionally falls back to MAC address, and
generates names based on these properties. This provides "location oriented"
names for PCI cards such as "enp0s1" for ethernet, or wlp1s0" for a WIFI card
so that replacing a broken network card does not change the name. As location
based naming does not work well for USB devices, these use a MAC based naming
schema (see /lib/udev/rules.d/73-usb-net-by-mac.rules).
This has been enabled by default since udev 220-7, which affects new
installations/hardware. Existing installations/hardware which already got
covered by the old 75-persistent-net-generator.rules will keep their interface
names, see below.
You can disable these stable names and go back to the kernel-provided ones
(which don't have a stable order) in one of two ways:
- Put "net.ifnames=0" into the kernel command line (e. g. in
/etc/default/grub's GRUB_CMDLINE_LINUX_DEFAULT, then run "update-grub").
- Disable the default *.link rules with
"ln -s /dev/null /etc/systemd/network/99-default.link"
and rebuild the initrd with "update-initramfs -u".
See this page for more information:
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
Legacy persistent network interface naming
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Debian releases up to 8 ("Jessie") and Ubuntu up to 15.04 had an udev rule
/lib/udev/rules.d/75-persistent-net-generator.rules which fixed the name of a
network interface that it got when its MAC address first appeared in a
dynamically created /etc/udev/rules.d/70-persistent-net.rules file.
This had inherent race conditions (which sometimes caused collisions and
interface names like "rename1"), required having to write state into /etc
(which isn't possible for read-only root), and did not work in virtualized
environments.
This old schema is deprecated in Debian 9 ("Stretch"), and will not
be supported any more in Debian 10.
Migration to the current network interface naming
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On package upgrade systems will keep their current names, but they will need to
be manually migrated by Debian 10 / Ubuntu 18.04 LTS. If you rely on the old
names in custom ifupdown stanzas, firewall scripts or other networking
configuration, these need to be updated to the new names.
First, determine all relevant network interface names: those in
/etc/udev/rules.d/70-persistent-net.rules, or if that does not exist (in
virtual machines), in "ip link" or /sys/class/net/.
Then for every interface name use a command like
grep -r eth0 /etc
to find out where it is being used.
Then on "real hardware" machines, rename the file to
70-persistent-net.rules.old; on VMs remove the file
/etc/udev/rules.d/80-net-setup-link.rules instead.
Reboot, adjust configuration files, and test your system.
Custom net interface naming
~~~~~~~~~~~~~~~~~~~~~~~~~~~
In some cases it is convenient to define your own specific names for network
interfaces. These can be customized in two different ways:
* You can create your own names via udev rules, based on arbitrary attribute
and property matches. See man udev(7) for documentation how to write udev
rules. For example, you can create /etc/udev/rules.d/76-netnames.rules with
------------ snip ----------
# identify device by MAC address
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="11:22:aa:bb:cc:33", NAME="eth-dmz"
# identify by vendor/model ID
SUBSYSTEM=="net", ACTION=="add", ENV{ID_VENDOR_ID}=="0x8086", \
ENV{ID_MODEL_ID}=="0x1502", NAME="eth-intel-gb"
# USB device by path
# get ID_PATH if not present yet
ENV{ID_PATH}=="", IMPORT{builtin}="path_id"
SUBSYSTEM=="net", ACTION=="add", ENV{ID_PATH}=="*-usb-0:3:1*", NAME="eth-blue-hub"
------------ snip ----------
The name of the rules file needs to have a prefix smaller than "80" so that
it runs before /lib/udev/rules.d/80-net-setup-link.rules, and should have a
prefix bigger than "75" so that it runs after 75-net-description.rules and
thus you can use matches on ID_VENDOR and similar properties.
* Unless you disabled net.ifnames, you can change the policy
(kernel/bios/path/MAC based naming) in an /etc/systemd/network/*.link file,
for individual devices or entire device classes. See man systemd.link(5) for
details about this. /lib/systemd/network/99-default.link is the default
policy, and /lib/systemd/network/01-mac-for-usb.link makes it use MAC based
names for USB devices.
Any of the above changes require an initrd update with "update-initramfs -u" to
get effective.
Using udev with LDAP or NIS
~~~~~~~~~~~~~~~~~~~~~~~~~~~
If the rules files reference usernames or groups not present in the
/etc/{passwd,group} files and the system is configured to use a
network-based database like LDAP or NIS then udev may fail at boot time
because users and groups are looked up well before the network has been
initialized.
A possible solution is to configure /etc/nsswitch.conf like this:
passwd: files ldap [UNAVAIL=return]
group: files ldap [UNAVAIL=return]
The nsswitch.conf syntax is documented in the glibc manual.
Michael Biebl
Jul 27, 2017, 3:30:07 PM7/27/17
to
Am 27.07.2017 um 20:21 schrieb Patrick Flaig:
> Sure, this is the content:
>
> cat /tmp/foo/lib/systemd/network/99-default.link
Thanks Patrick.
> Sure, this is the content:
>
> cat /tmp/foo/lib/systemd/network/99-default.link
So, it seems the udev maintainer scripts detected at virtualized
environment which causes the following code to be triggered:
https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/udev.postinst#n49
The /etc/systemd/network/99-default.link file overrides the the package
provided one from /lib/systemd/network/99-default.link
So, in order to enable the new naming scheme, remove
/etc/systemd/network/99-default.link then rebuild the initramfs.
On the next boot you should have the new network interface names.
Regards,
Michael
Patrick Flaig
Jul 27, 2017, 4:20:05 PM7/27/17
to
Hi Michael,
great, that was the problem, removed the file, recreated the initramfs, now it works like a charm.
Thanks a lot for the help.
Patrick
great, that was the problem, removed the file, recreated the initramfs, now it works like a charm.
Thanks a lot for the help.
Patrick
0 new messages