Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 453494 - >=sys-fs/udev-197: Document the change in interface name swapping for pre-197 rule file 70-persistent-net.rules
Summary: >=sys-fs/udev-197: Document the change in interface name swapping for pre-197...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High normal with 2 votes (vote)
Assignee: udev maintainers
URL: http://www.freedesktop.org/wiki/Softw...
Whiteboard: http://cgit.freedesktop.org/systemd/s...
Keywords:
: 450938 453030 455822 460614 461516 462082 463296 (view as bug list)
Depends on:
Blocks: 411627
  Show dependency tree
 
Reported: 2013-01-22 09:53 UTC by Sergey Popov
Modified: 2013-04-03 13:15 UTC (History)
22 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Edit this and put it into sysinit runlevel (ethtmp,243 bytes, text/plain)
2013-01-23 10:11 UTC, Samuli Suominen (RETIRED)
Details
Loop eth1-eth9999 and be silent about it (ethtmp,481 bytes, text/plain)
2013-01-23 10:28 UTC, Samuli Suominen (RETIRED)
Details
Workaround init script (ethtmp,546 bytes, text/plain)
2013-01-23 10:31 UTC, Samuli Suominen (RETIRED)
Details
Workaround init script to temporarily rename to eg. eth0tmp (ethtmp,605 bytes, text/plain)
2013-01-23 10:37 UTC, Samuli Suominen (RETIRED)
Details
rc.log of ethX-rename failure (t,5.74 KB, text/plain)
2013-01-24 20:45 UTC, Norman Back
Details
ethX_rename (rename_ethX.sh,691 bytes, text/plain)
2013-01-24 22:19 UTC, Alexander Tsoy
Details
net-name-test.sh (net-name-test.sh,144 bytes, text/plain)
2013-02-06 13:13 UTC, Derk W te Bokkel
Details
net-name-test.sh (net-name-test.sh,101 bytes, text/x-sh)
2013-03-14 22:30 UTC, William Hubbs
Details
net-name-test.sh (net-name-test.sh,609 bytes, text/x-sh)
2013-03-15 05:43 UTC, William Hubbs
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Popov gentoo-dev 2013-01-22 09:53:25 UTC
In short - it's ignored when NIC drivers compiled in kernel.

admin@zeus ~ $ cat /etc/udev/rules.d/70-persistent-net.rules 
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:85", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:fd", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

admin@zeus ~ $ zcat /proc/config.gz | grep E1000E
CONFIG_E1000E=y

Actual result:

When i rebooted, i have got:

admin@zeus ~ $ ifconfig | grep eth.: -A3
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::beae:c5ff:fe59:5a85  prefixlen 64  scopeid 0x20<link>
        ether bc:ae:c5:59:5a:fd txqueuelen 1000  (Ethernet)
        RX packets 25452  bytes 3656201 (3.4 MiB)
--
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.8.0.61  netmask 255.255.255.0  broadcast 10.8.0.255
        inet6 fe80::beae:c5ff:fe59:5afd  prefixlen 64  scopeid 0x20<link>
        ether bc:ae:c5:59:5a:85  txqueuelen 1000  (Ethernet)

Look carefully into MAC addresses and device names.

Expected result:

admin@zeus ~ $ ifconfig | grep eth.: -A3
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::beae:c5ff:fe59:5a85  prefixlen 64  scopeid 0x20<link>
        ether bc:ae:c5:59:5a:85  txqueuelen 1000  (Ethernet)
        RX packets 25452  bytes 3656201 (3.4 MiB)
--
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.8.0.61  netmask 255.255.255.0  broadcast 10.8.0.255
        inet6 fe80::beae:c5ff:fe59:5afd  prefixlen 64  scopeid 0x20<link>
        ether bc:ae:c5:59:5a:fd  txqueuelen 1000  (Ethernet)


I have got expected result ONLY after i recompile e1000e driver as module:

admin@zeus ~ $ zcat /proc/config.gz | grep E1000E
CONFIG_E1000E=m

Parsing udev and udevadm logs in old and new versions gives me no clue about what happens, but old udev(171-r10) does not have this problem

emerge --info:
admin@zeus ~ $ emerge --info
Portage 2.1.11.31 (default/linux/amd64/10.0, gcc-4.6.3, glibc-2.15-r3, 3.5.7-gentoo-ZEUS x86_64)
=================================================================
System uname: Linux-3.5.7-gentoo-ZEUS-x86_64-Intel-R-_Xeon-R-_CPU_E5640_@_2.67GHz-with-gentoo-2.1
Timestamp of tree: Mon, 21 Jan 2013 20:30:01 +0000
ld GNU ld (GNU Binutils) 2.22
app-shells/bash:          4.2_p37
dev-lang/python:          2.7.3-r2
dev-util/pkgconfig:       0.27.1
sys-apps/baselayout:      2.1-r1
sys-apps/openrc:          0.11.8
sys-apps/sandbox:         2.5
sys-devel/autoconf:       2.68
sys-devel/automake:       1.11.6
sys-devel/binutils:       2.22-r1
sys-devel/gcc:            4.5.4, 4.6.3
sys-devel/gcc-config:     1.7.3
sys-devel/libtool:        2.4-r1
sys-devel/make:           3.82-r4
sys-kernel/linux-headers: 3.6 (virtual/os-headers)
sys-libs/glibc:           2.15-r3
Repositories: gentoo
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--keep-going --jobs=3"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="ftp://ftp.dstu.local/UNIX/Repos/Gentoo"
LANG="ru_RU.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j17"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.dstu.local/gentoo-portage"
USE="acl amd64 bzip2 cli cracklib crypt cxx dri fortran gpm iconv ipv6 mmx modules mudflap multilib ncurses nls nptl openmp pam pcre readline session sse sse2 ssl syslog tcpd threads unicode zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="ru" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7" QEMU_SOFTMMU_TARGETS="i386 x86_64" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Comment 1 Alexander Tsoy 2013-01-22 10:13:05 UTC
You should use names for interfaces which are differ from the internal kernel names (netNN, lanNN, iternetNN, etc).
Comment 2 Sergey Popov gentoo-dev 2013-01-22 10:15:21 UTC
(In reply to comment #1)
> You should use names for interfaces which are differ from the internal
> kernel names (netNN, lanNN, iternetNN, etc).

If it's not official upstream position(we do not support flawless upgrade), then - no i do not :-). At least - not in such important system part as udev.
Comment 3 Alexander Tsoy 2013-01-22 10:16:05 UTC
Also see bug 433746
Comment 4 Samuli Suominen (RETIRED) gentoo-dev 2013-01-22 10:17:51 UTC
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:85", NAME="net0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:fd", NAME="net1"

try above for me

i'd rename the file to something else starting with 70- ;)
Comment 5 Samuli Suominen (RETIRED) gentoo-dev 2013-01-22 10:20:36 UTC
(In reply to comment #4)
> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:85",
> NAME="net0"
> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:fd",
> NAME="net1"

eth, not net
Comment 6 Alexander Tsoy 2013-01-22 12:11:44 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > You should use names for interfaces which are differ from the internal
> > kernel names (netNN, lanNN, iternetNN, etc).
> 
> If it's not official upstream position(we do not support flawless upgrade),
> then - no i do not :-). At least - not in such important system part as udev.

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

"The biggest of all however is that the userspace components trying to assign the interface name raced against the kernel assigning new names from the same "ethX" namespace, a race condition with all kinds of weird effects, among them that assignment of names sometimes failed. As a result support for this has been removed from systemd/udev a while back."
Comment 7 Alexander Tsoy 2013-01-22 12:28:18 UTC
Also proof from Kay Sievers:

https://bugzilla.redhat.com/show_bug.cgi?id=782145#c3
Comment 8 William Hubbs gentoo-dev 2013-01-22 15:54:25 UTC
The issue here is that the kernel never allowed you to rename a net
device to the name of another existing net device, but older versions of
udev did extra work to allow this. This version of udev no longer has
this extra processing.
Comment 9 Samuli Suominen (RETIRED) gentoo-dev 2013-01-22 16:04:30 UTC
(In reply to comment #8)
> The issue here is that the kernel never allowed you to rename a net
> device to the name of another existing net device, but older versions of
> udev did extra work to allow this. This version of udev no longer has
> this extra processing.

Shouldn't the syntax from Comment #4 if using net0 and net1 work? It just doesn't work for eth*? Confused.
Comment 10 Mike Gilbert gentoo-dev 2013-01-22 16:20:29 UTC
(In reply to comment #9)

Yes, your example as given in comment 4 should work fine.
Comment 11 William Hubbs gentoo-dev 2013-01-22 19:36:32 UTC
(In reply to comment #9)
> Shouldn't the syntax from Comment #4 if using net0 and net1 work? It just
> doesn't work for eth*? Confused.

Yes, you are correct, but maybe I was confused as well, because comment #5 seems to be a correction saying that the person should use eth* instead of net*.
Comment 12 Samuli Suominen (RETIRED) gentoo-dev 2013-01-22 23:47:09 UTC
(In reply to comment #11)
> (In reply to comment #9)
> > Shouldn't the syntax from Comment #4 if using net0 and net1 work? It just
> > doesn't work for eth*? Confused.
> 
> Yes, you are correct, but maybe I was confused as well, because comment #5
> seems to be a correction saying that the person should use eth* instead of
> net*.

After renaming them to net0 and net1, shouldn't it be possible to re-rename them back to eth0 and eth1?

Would it work to have...

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:85", NAME="net0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:fd", NAME="net1"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:85", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:fd", NAME="eth1"

Or in a different file? I think Joky (Freenode) was using a workaround like this. Use temporary names and not direct swapping...

Just trying to get something together for postinst message/news item...
Comment 13 Mike Gilbert gentoo-dev 2013-01-23 00:04:59 UTC
I think I tried that, and it didn't work. Maybe udev reads the entire config and then executes the resulting rules? I'm not sure.
Comment 14 Alexander Tsoy 2013-01-23 09:18:49 UTC
(In reply to comment #13)
> I think I tried that, and it didn't work. Maybe udev reads the entire config
> and then executes the resulting rules? I'm not sure.

AFAIK you are right.


Temporary renaming of "ethX: to another name "renameX" was done internally by udev, not via rules. And this code was removed:
http://cgit.freedesktop.org/systemd/systemd/commit/src/udev?id=97595710b77aa162ca5e20da57d0a1ed7355eaad
Comment 15 Samuli Suominen (RETIRED) gentoo-dev 2013-01-23 10:06:57 UTC
*** Bug 453030 has been marked as a duplicate of this bug. ***
Comment 16 Samuli Suominen (RETIRED) gentoo-dev 2013-01-23 10:11:51 UTC
Created attachment 336566 [details]
Edit this and put it into sysinit runlevel

Here is a workaround that Christian is using. It has numbers hardcoded so editing is required.

So swapping is no longer possible and the dropping of it was intention. Okay, we have to deal with that. I looked at reverting the code but it no longer applies cleanly and I won't be doing it.

So what we could do is provide this example workaround enchanced to the users and issue a news item? Does that sound sane?
Comment 17 Samuli Suominen (RETIRED) gentoo-dev 2013-01-23 10:17:35 UTC
Comment on attachment 336566 [details]
Edit this and put it into sysinit runlevel

Uses sys-apps/iproute2 which unfortunately isn't part of the system (yet)
Comment 18 Samuli Suominen (RETIRED) gentoo-dev 2013-01-23 10:22:17 UTC
(In reply to comment #17)
> Comment on attachment 336566 [details]
> Edit this and put it into sysinit runlevel
> 
> Uses sys-apps/iproute2 which unfortunately isn't part of the system (yet)

hint: for i in {1..9999}; do
Comment 19 Samuli Suominen (RETIRED) gentoo-dev 2013-01-23 10:28:32 UTC
Created attachment 336568 [details]
Loop eth1-eth9999 and be silent about it
Comment 20 Samuli Suominen (RETIRED) gentoo-dev 2013-01-23 10:31:22 UTC
Created attachment 336570 [details]
Workaround init script
Comment 21 Samuli Suominen (RETIRED) gentoo-dev 2013-01-23 10:37:43 UTC
Created attachment 336574 [details]
Workaround init script to temporarily rename to eg. eth0tmp

0..9999 and comment about iproute2
Comment 22 Samuli Suominen (RETIRED) gentoo-dev 2013-01-23 11:16:01 UTC
ebuild now has postinst message, that's the very least we can do
Comment 23 Samuli Suominen (RETIRED) gentoo-dev 2013-01-23 18:01:38 UTC
(In reply to comment #22)
> ebuild now has postinst message, that's the very least we can do

and it's now part of the news item committed today
Comment 24 Nebojsa Trpkovic 2013-01-24 19:45:48 UTC
script looks nice.
does it help?

I would not like to risk rebooting some remote servers without being sure I'll be able to access them...
Comment 25 Norman Back 2013-01-24 20:43:51 UTC
(In reply to comment #21)
> Created attachment 336574 [details]
> Workaround init script to temporarily rename to eg. eth0tmp
> 
> 0..9999 and comment about iproute2

I fell over this yesterday when the HDD on my Gentoo multi WAN router crashed and I tried to rebuild it.

Having read this bug I now understand the issues I had with the network card reordering.

I have tried using the attached script, placing it in /etc/init.d/ethX-rename but it fails. See the attached rc.log. 

I feel I must be missing some other configuration setting somewhere. Help!
Comment 26 Norman Back 2013-01-24 20:45:28 UTC
Created attachment 336766 [details]
rc.log of ethX-rename failure
Comment 27 Alexander Tsoy 2013-01-24 21:08:00 UTC
(In reply to comment #26)
> Created attachment 336766 [details]
> rc.log of ethX-rename failure

start() in this initscript will always return false because you really don't have 9999 interfaces. This is normal. Do you really experience problems with persistent network names setup?
Comment 28 Tomáš Bžatek 2013-01-24 21:52:07 UTC
FYI, if you have eth drivers compiled as modules, the above script won't work since it's started "before dev" and eth modules are not loaded yet. The modules service starts somewhere after udev.

For this to work, you need to modify the script to include "need modules" in depend() and manually specify required modules in /etc/conf.d/modules

With old 70-persistent-net.rules this works as expected with new udev.
Comment 29 Norman Back 2013-01-24 22:09:25 UTC
(In reply to comment #28)
> FYI, if you have eth drivers compiled as modules, the above script won't
> work since it's started "before dev" and eth modules are not loaded yet. The
> modules service starts somewhere after udev.
> 
> For this to work, you need to modify the script to include "need modules" in
> depend() and manually specify required modules in /etc/conf.d/modules
> 
> With old 70-persistent-net.rules this works as expected with new udev.

My eth drivers are compiled as modules. I'll try the above. Thanks.
Comment 30 Alexander Tsoy 2013-01-24 22:19:05 UTC
Created attachment 336774 [details]
ethX_rename

Slightly modified version of the script.
Comment 31 Samuli Suominen (RETIRED) gentoo-dev 2013-01-25 04:12:17 UTC
(In reply to comment #30)
> Created attachment 336774 [details]
> ethX_rename
> 
> Slightly modified version of the script.

this was exactly my intention when dropping the script here that people would edit and improve it. thanks.
Comment 32 Oliver Jaksch 2013-01-25 10:08:04 UTC
(coming from bug #453030)
Can confirm that swapping/renaming of my two eth's is working now again as before udev update. With the script of comment #30 the 70-net rule ist working as usual. *phew*
Thanks everybody who helped on this...
Comment 33 Robert Tongue 2013-01-25 13:11:58 UTC
Also had positive results with script in comment 30. Finally have persistent names for both net cards in my server. Was touch and go for the last 2 days trying to get it to work. I guess I should have waited two more days to upgrade udev. Thanks for the script. Lifesaver, you are. :D
Comment 34 Nick Bowler 2013-01-25 15:01:29 UTC
The recent news message "Upgrading udev from 171 (or older) to 197" told me that I *need* to read this bug report (emphasis mine).

I have read this bug report, but I have no idea what I am supposed to take away from this.
Comment 35 orionbelt2 2013-01-25 15:40:07 UTC
In the news item about this issue one reads:

"need to verify the fstype for possible /dev line in /etc/fstab is devtmpfs (and not, for example, tmpfs)"

Does this mean that the usual /etc/fstab line:

shm  /dev/shm tmpfs nodev,nosuid,noexec 0 0

should be replaced by

shm  /dev/shm devtmpfs nodev,nosuid,noexec 0 0

? Or does the news comment refer to the case where one might have an fstab line that makes reference to /dev/tmpfs?...

I suspect fstab is OK the way it is, but would just like to make sure before rebooting... Thanks :)
Comment 36 Samuli Suominen (RETIRED) gentoo-dev 2013-01-25 17:09:24 UTC
(In reply to comment #35)
> In the news item about this issue one reads:

Use forums.gentoo.org for such questions, this is a bug about the networking change.

With that said, the news item says /dev so it means /dev not /dev/shm. I don't have such /dev/shm line in my fstab at all, but yet shm is mounted automatically correctly so I'm not sure why you have it there in the first place.
Comment 37 Navid Zamani 2013-01-26 11:27:08 UTC
The thing is: This bug, which we according to the news item are supposed to read, is still completely useless to us.

You do not seriously expect us to make an init script based on that ethX_rename file attached here, to keep renaming working, do you?
Because that is a horrible hack.

A transparent solution is required here.

To me it makes no sense, that useful functionality was deliberately removed for no reason. This is not Gnome or Apple.
(That race condition could have been solved inside udev.)

So we’re still stuck, and this bug is not resolved.
Comment 38 Martin 2013-01-26 14:46:47 UTC
(In reply to comment #37)
> The thing is: This bug, which we according to the news item are supposed to
> read, is still completely useless to us.
> 
> You do not seriously expect us to make an init script based on that
> ethX_rename file attached here, to keep renaming working, do you?
> Because that is a horrible hack.
> 
> A transparent solution is required here.

[...]

> So we’re still stuck, and this bug is not resolved.

I agree.

Reading carefully this bug series, I follow what has happened but there is no good solution offered. And it takes a good while to follow what has happened.

I am reminded of the recent passion from Linus about breaking user-space... ;-)


My action is to hold off further upgrades until there is some dire need to spend hours hacking multiple servers with multiple network interfaces...

Or until there is a transparent fix?

Help?

Regards,
Martin
Comment 39 Martin 2013-01-26 15:31:00 UTC
(In reply to comment #38)
> (In reply to comment #37)
> > The thing is: This bug, which we according to the news item are supposed to
> > read, is still completely useless to us.
> > 
[...]
> 
> I am reminded of the recent passion from Linus about breaking user-space...
> ;-)
> 
> 
> My action is to hold off further upgrades until there is some dire need to
> spend hours hacking multiple servers with multiple network interfaces...
> 
> Or until there is a transparent fix?

FYI:

After reading through:

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames


That is a very good idea for new installs. Unfortunately, somewhat disruptive for existing systems. Also, all this is going to take an awful lot of reading by ALL users...!

My solution is the manual option of:


You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's rule file for the default policy:

ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules


(I'll be trying the new naming scheme on a new test install.)

So... How to fix this easily for existing users?

Regards,
Martin
Comment 40 Uros 2013-01-26 17:12:57 UTC
Well, it seems that this is (still) working after upgrade from 171-r10 -> 197-r3.. at least on my stable install. I've updated /etc/udev/rules.d/70-persistent-net.rules based on https://forums.gentoo.org/viewtopic-p-7230178.html#7230178 post, and after reboot my interface names were there, setup as defined.

What I did is strip everything but SUBSYSTEM, ACTION, ATTR{address} and NAME from each entry and left 80-net-name-slot.rules in place.

So, if someone else could validate this, package postinst message could be changed.
Comment 41 Samuli Suominen (RETIRED) gentoo-dev 2013-01-26 18:03:47 UTC
I don't expect anyone to use the workaround script as a permanent solution. I'm expecting people to use the new precictable netwok scheme. The script here is only for people who had their setup at production server installed and are in need for urgent workaround before they get a better time to finish the upgrade. As in, switch to the predictable naming scheme.

However patches are accepted, if you really have better idea. Otherwise you can just shup up. No offense ;-)
Comment 42 Samuli Suominen (RETIRED) gentoo-dev 2013-01-26 21:58:09 UTC
*** Bug 450938 has been marked as a duplicate of this bug. ***
Comment 43 Derk W te Bokkel 2013-02-06 13:13:16 UTC
Created attachment 338090 [details]
net-name-test.sh

from bug 455882

perhaps in view of the confusion reigning over the new net naming convention with newer udev's a name testing script should be included for the clueless?

code is not original but from the forums:

http://forums.gentoo.org/viewtopic-p-7240454.html#7240454  

I just put it into a script for general use




I found the command line from /etc/udev/rules.d/80-net-name-slot.rules

udevadm test-builtin net_id /sys/class/net/ifname 2> /dev/null

give no info at all .. as ifname seems not to exist ..  of course my machine is on the new rules but the method should still work as a reboot may have occurred prior to the  use of the line ..
Comment 44 Derk W te Bokkel 2013-02-06 13:14:05 UTC
*** Bug 455822 has been marked as a duplicate of this bug. ***
Comment 45 Derk W te Bokkel 2013-02-06 13:18:08 UTC
error info for https://bugs.gentoo.org/show_bug.cgi?id=453494#c43


udevadm test-builtin net_id /sys/class/net/ifname 
calling: test-builtin
=== trie on-disk ===
tool version:          197
file size:         5518899 bytes
header size             80 bytes
strings            1237475 bytes
nodes              4281344 bytes
load module index
unable to open device '/sys/class/net/ifname'

unload module index
Comment 46 Alexander Tsoy 2013-02-06 13:27:55 UTC
Replace "ifname" with the actual interface name.
Comment 47 Derk W te Bokkel 2013-02-06 13:30:29 UTC
udevadm test-builtin net_id /sys/class/net/*
Password: 
calling: test-builtin
=== trie on-disk ===
tool version:          197
file size:         5518899 bytes
header size             80 bytes
strings            1237475 bytes
nodes              4281344 bytes
load module index
ID_NET_NAME_MAC=enx0023545b3d7f
ID_OUI_FROM_DATABASE=ASUSTek COMPUTER INC.
ID_NET_NAME_PATH=enp12s0
unload module index


works better but does not grab the wireless cards as the net-name-test.sh script does. please change the documentation
Comment 48 Derk W te Bokkel 2013-02-06 13:37:36 UTC
in fact the one liner relies on net names being alphabetical and grabs the first entry only?  Is this true?
Comment 49 William Hubbs gentoo-dev 2013-02-06 14:42:09 UTC
(In reply to comment #47)
> udevadm test-builtin net_id /sys/class/net/*

Don't use wildcards; you have to run the command separately for each interface.
Comment 50 Derk W te Bokkel 2013-02-06 17:57:44 UTC

(In reply to comment #49)

> Don't use wildcards; you have to run the command separately for each
> interface.


for the novice .. a wild card works ..  better is perhaps ..

ls /sys/class/net/

to identify all available network interfaces

then run the command ..

udevadm test-builtin net_id /sys/class/net/{specific-name}

.. if the actual names are not known .. i.e. not the old defaults eth0, eth1 etc.
Comment 51 Robert W. 2013-02-16 16:56:32 UTC
I just did the upgrade to udev-197-r8. I removed 70-persistent-net.rules and 80-net-name-slot.rules. Networkmanager was unable to connect to any wireless network.

Feb 16 17:03:20 [NetworkManager] <info> wpa_supplicant started
Feb 16 17:03:20 [NetworkManager] <info> (wlp2s0): supplicant interface state: starting -> ready
Feb 16 17:03:20 [NetworkManager] <info> (wlp2s0): device state change: unavailable -> disconnected (reason 'supplicant-available') [20 30 42]
Feb 16 17:03:20 [NetworkManager] <warn> Trying to remove a non-existant call id.
Feb 16 17:03:20 [NetworkManager] <info> (wlp2s0): supplicant interface state: ready -> inactive

After deleting /etc/conf.d/net all problems were gone and it now works fine. I suggest to put the hint into the message of the udev-ebuild.
Comment 52 William Hubbs gentoo-dev 2013-02-16 20:10:44 UTC
(In reply to comment #51)
> I just did the upgrade to udev-197-r8. I removed 70-persistent-net.rules and
> 80-net-name-slot.rules. Networkmanager was unable to connect to any wireless
> network.

*snip*

> After deleting /etc/conf.d/net all problems were gone and it now works fine.
> I suggest to put the hint into the message of the udev-ebuild.

Since you are using networkmanager, The only net.* service you should have in your runlevels is net.lo. You should not have to remove /etc/conf.d/net.
Can you please confirm that you do not have any other net.* services in your runlevels?
Comment 53 Martin 2013-02-23 23:08:27 UTC
(In reply to comment #39)
> (In reply to comment #38)
> > (In reply to comment #37)
> > > The thing is: This bug, which we according to the news item are supposed to
> > > read, is still completely useless to us.
> > > 
> [...]
> > 
> > I am reminded of the recent passion from Linus about breaking user-space...
> > ;-)


> My solution is the manual option of:
> 
> 
> You disable the assignment of fixed names, so that the unpredictable kernel
> names are used again. For this, simply mask udev's rule file for the default
> policy:
> 
> ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules

That looks to have been done already by the installation of the gentoo dummy file, good thanks:

/etc/udev/rules.d/80-net-name-slot.rules


For upgrading one of my systems, I then additionally:

Deleted /etc/udev/rules.d/70-persistent-net.rules

Recompiled the (custom) kernel for enabling the CONFIG_DEVTMPFS=y feature (thanks for the emerge notes and checks for that). I also enabled CONFIG_DEVTMPFS_MOUNT=y just in case... (Note: Recompiling is not necessary for those users using the normal Gentoo genkernel!)

Added early into /etc/fstab:

devtmpfs            /dev        devtmpfs    defaults            0 0


Reboot saw the expected reshuffling of the network cards eth numbers... That was fixed by renumbering the eths in the Shorewall interfaces file and in the Gentoo net config /etc/conf.d/net to match.


> So... How to fix this easily for existing users?

That's one machine... Hopefully, multi-nic machines are rare?


Cheers,
Martin
Comment 54 Martin 2013-02-24 14:55:31 UTC
(In reply to comment #53)

> For upgrading one of my systems, I then additionally:
> 
> Deleted /etc/udev/rules.d/70-persistent-net.rules
> 
> Recompiled the (custom) kernel for enabling the CONFIG_DEVTMPFS=y feature
> (thanks for the emerge notes and checks for that). I also enabled
> CONFIG_DEVTMPFS_MOUNT=y just in case... (Note: Recompiling is not necessary
> for those users using the normal Gentoo genkernel!)
> 
> Added early into /etc/fstab:
> 
> devtmpfs            /dev        devtmpfs    defaults            0 0
> 
> 
> Reboot saw the expected reshuffling of the network cards eth numbers... That
> was fixed by renumbering the eths in the Shorewall interfaces file and in
> the Gentoo net config /etc/conf.d/net to match.

Ooooops! For anyone following that, also needed (as root):

rc-update delete udev-postmount


Good luck,
Martin
Comment 55 Samuli Suominen (RETIRED) gentoo-dev 2013-03-08 19:23:46 UTC
*** Bug 460614 has been marked as a duplicate of this bug. ***
Comment 56 William Hubbs gentoo-dev 2013-03-13 17:42:04 UTC
*** Bug 461516 has been marked as a duplicate of this bug. ***
Comment 57 Igor Franchuk 2013-03-13 19:35:10 UTC
I'm having the same problem and with the drivers built into the kernel none of the above quick-arounds worked. Is there any solution?
I'm voting for banning the udev developer who did make this update in this radical un-thoughtful fashion. It broke many servers and wasted many hours of many gentoo-users. The reason for this update is unknown. Let's users decide what they want.
Comment 58 Samuli Suominen (RETIRED) gentoo-dev 2013-03-13 21:24:01 UTC
(In reply to comment #57)
> I'm having the same problem and with the drivers built into the kernel none
> of the above quick-arounds worked. Is there any solution?

Sure, use free namespace instead of kernel reserved namespace and rename to for example, net0, net1, net2

Or remove both 70-persistent-* 80-net-name-slot.rules from /etc/udev/rules.d
and run following command to get the required information BEFORE booting:

# udevadm test-builtin net_id /sys/class/net/<ifname> 2> /dev/null

Both are very quick ways.

And this is the upstream default. Disabling this default would mean relying to the kernel named devices which can be random, that may even has security implications. The names must be predictable, and that's the beauty of it, no need for renaming them at all anymore!

And rest of your message was just rude, moaning over upstream replacing one feature with better feature doesn't help
Comment 59 Igor Franchuk 2013-03-13 23:48:01 UTC
In my case I had a kernel with built-in two network interface drivers. After upgrading to the new udev the server went offline. The problem was that 70-persistent-net.rules were no longer applied and eth0 became eth1 and vice versa. The routing rules in /etc/conf.d/net were applied to eth1 and the server went offline. 

Could you please explain how removing 70-persistent-* 80-net-name-slot.rules will help to get eth0 as eth0 back and eth1 as eth1? 

Would I have to re-configure ./conf.d/net? since they refer to eth0, eth1?

Could you please demonstrate the beauty of the new update? I've been using eth0, eth1 configs for many many many years and I fail to see the beauty of the new udev. 

How can I migrate to the new UDEV leaving old ./conf.d/net? 

Why there is no backward compatibility? Is getting servers offline being a new idea of beauty? This is rude self-relying and mindless way of issuing an update and I don't feel rude calling it these names and I vote for a year ban of the developer of this update before he can ruin something with the new one. And I'm sure a lot of people feel the same about it.

(In reply to comment #58)
> (In reply to comment #57)
> > I'm having the same problem and with the drivers built into the kernel none
> > of the above quick-arounds worked. Is there any solution?
> 
> Sure, use free namespace instead of kernel reserved namespace and rename to
> for example, net0, net1, net2
> 
> Or remove both 70-persistent-* 80-net-name-slot.rules from /etc/udev/rules.d
> and run following command to get the required information BEFORE booting:
> 
> # udevadm test-builtin net_id /sys/class/net/<ifname> 2> /dev/null
> 
> Both are very quick ways.
> 
> And this is the upstream default. Disabling this default would mean relying
> to the kernel named devices which can be random, that may even has security
> implications. The names must be predictable, and that's the beauty of it, no
> need for renaming them at all anymore!
> 
> And rest of your message was just rude, moaning over upstream replacing one
> feature with better feature doesn't help
Comment 60 Igor Franchuk 2013-03-13 23:55:15 UTC
If anyone knows how to get my eth0 as eth0 and eth1 as eth1 back with built-in kernel network drivers instead of having eth0 as eth1 and eth1 as eth0 with the new sound and beautiful UDEV and the old /conf.d/net I would appreciate a step-by-step instructions (and I'm sure many will). What should I do to boot the the computer with the same config and experience the beauty of UDEV in it's full?
Comment 61 Derk W te Bokkel 2013-03-14 00:47:08 UTC
for /etc/conf.d/net

you need to search and replace eth0 w/ enp?????  what ever the new name is ..
and eth1 w/ enpxxxxx  also what ever that happens to be .. will be unique to your mother board, installed cards and slots used .. use net-name-test.sh  to id the cards (be sure to chmod +x net-name-test.sh )

also rename /etc/init.d/net.eth0 and net.eth1 to the same as above i.e. net.enp????? and net.enpxxxxx  as per example .. then all should  work ..
Comment 62 Igor Franchuk 2013-03-14 06:38:54 UTC
I thought that will go that. Now I'm sure, thank you, it's now clear. 

How about net configs and routing information that are replicated to the servers is it no go from now? I find it at least equally simple to have a unique rule assigning eth0 and eth1 than to have unique conf.d/net configs. What is simpler to type /etc/init.d/net.eth0 restart than net.enp2s0 restart. 

The problem is worse. Now you never know what is your FIRST and SECOND or THIRD or FOURTH network interface. How to know? If all nics are of the same make then without the old persistent file it's hard to understand even what pathcord is connected to what interface. 

Now to find what is what I have lspci first 
then

cat /proc/net/dev/ 

then compare DEVICE_ID

And how now I should know what interface I should restart. Earlier I knew that eth0 is always the input with the first pathcord. Now how do I know what ID  first pathcord is connected to? It will differ from machine to machine - it's kind of hell if you have 100 of them. 

I don't remember device ids, and especially I don't want them to be unique on each server. If fact I want each sever to have the same eth0 referring to the first path cord, eth1 to the second and eth3 to the spare. 

This update should be masked it's not ready, it's alpha or even pre-alpha. 

(In reply to comment #61)
> for /etc/conf.d/net
> 
> you need to search and replace eth0 w/ enp?????  what ever the new name is ..
> and eth1 w/ enpxxxxx  also what ever that happens to be .. will be unique to
> your mother board, installed cards and slots used .. use net-name-test.sh 
> to id the cards (be sure to chmod +x net-name-test.sh )
> 
> also rename /etc/init.d/net.eth0 and net.eth1 to the same as above i.e.
> net.enp????? and net.enpxxxxx  as per example .. then all should  work ..
Comment 63 Igor Franchuk 2013-03-14 07:07:44 UTC
The situation is aggravated I just noticed that iptables are all broken too :-( of course they are they refer to eth0, eth1, eth2, eht3 of which I myself lost traces of.

The backward compatibility should be restored. It's no way the new UDEV will work.

If anyone wants to spend months in a data-centers experiencing the beauty of the new UDEV - let him go ahead. I'm for the old nasty udev. And to think of that if anything is used successfully for many years by many people then why exterminate the code which served well. Not evolve but exterminate. This is so amateur.

This update is nearly the worst what happened to us in the past 4 years. It's lucky only a few servers were updated.
Comment 64 Samuli Suominen (RETIRED) gentoo-dev 2013-03-14 08:20:10 UTC
(In reply to comment #62)
> The problem is worse. Now you never know what is your FIRST and SECOND or
> THIRD or FOURTH network interface. How to know? If all nics are of the same
> make then without the old persistent file it's hard to understand even what
> pathcord is connected to what interface. 

Quite the opposite, now you don't have to rename and always know which will be what
Sounds like you need to (re)read http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

Did you have any real issues? Parsing your comments didn't reveal any.
Comment 65 Martin 2013-03-14 11:22:01 UTC
> Did you have any real issues? Parsing your comments didn't reveal any.

Please reread this bug thread.

The scenario for any multi-network-interface system is:

Working system;
Apply udev update;
Without adequate warning or checks, broken system;
Then add three hours to read arcane detail, trace hardware and network leads, and re-hack multiple config files that have nothing to do with udev;
Working system oncemore and a sys-op feeling like a road crash.


Thankfully, I had the sense to try the update on a non-essential system first. That painful update means that I am not updating other systems for the time being until there is a smoother non-broken upgrade path.

Consistent device names is a good idea. However, translation to a human readable non-finger-breaking easily used form is essential.

I'm observing until I'm forced to put more time into this for other systems.


Thank you for working on this and for sorting out the code this far. Sorry, but the present update is too painful for collateral damage for forcing radical changes to existing configs for some existing systems.

(And amongst others, I have two live servers that have 8 network ports each, all utilised with individual firewalling and traffic management... That will be a full overnight job each to safely update and reconfig those. :-( )

Regards,
Martin
Comment 66 Martin 2013-03-14 11:37:52 UTC
(In reply to comment #54)
> (In reply to comment #53)
> 
> > For upgrading one of my systems, I then additionally:
> > 
> > Deleted /etc/udev/rules.d/70-persistent-net.rules
> > 
> > Recompiled the (custom) kernel for enabling the CONFIG_DEVTMPFS=y feature
> > (thanks for the emerge notes and checks for that). I also enabled
> > CONFIG_DEVTMPFS_MOUNT=y just in case... (Note: Recompiling is not necessary
> > for those users using the normal Gentoo genkernel!)
> > 
> > Added early into /etc/fstab:
> > 
> > devtmpfs            /dev        devtmpfs    defaults            0 0
> > 
> > 
> > Reboot saw the expected reshuffling of the network cards eth numbers... That
> > was fixed by renumbering the eths in the Shorewall interfaces file and in
> > the Gentoo net config /etc/conf.d/net to match.
> 
> Ooooops! For anyone following that, also needed (as root):
> 
> rc-update delete udev-postmount

Ooops... There's been other bits needing tweaking. An important one if you are using tc traffic management is to also re-hack the Shorewall tcstart file for whatever new interface names.

Also do a

egrep -R 'eth[0-9]' /etc

to pick up any others.

For my 'simple' test server example, after the fixes that gives:

/etc/asterisk/phoneprov.conf
/etc/dhcp/dhcpd.conf
/etc/shorewall.ml02.modem/tcstart.mp01
/etc/shorewall.ml02.modem/tcstart
/etc/shorewall.ml02.modem/params
/etc/yp.conf
/etc/shorewall.ml01/tcstart.mp01
/etc/shorewall.ml01/tcstart
/etc/shorewall.ml01/params.ml01
/etc/shorewall.ml01/params
/etc/udev/rules.d/80-net-name-slot.rules
/etc/asterisk.ml02/phoneprov.conf
/etc/rc.conf
/etc/asterisk.ml01/phoneprov.conf
/etc/shorewall/tcstart.mp01
/etc/shorewall/tcstart
/etc/shorewall/params.ml01
/etc/shorewall/params
/etc/conf.d/net
/etc/conf.d/network
/etc/conf.d/netmount


(And for example, people are very touchy about losing asterisk even for a minute... :-( )

Good luck,
Martin
Comment 67 Martin 2013-03-14 11:51:21 UTC
Sorry, I've not checked what whatever present warning messages are given before an update, but can this scenario be put in place as a fix:

Give a "dumb-speak" warning saying that the network interface names will be changed and this may break other system settings. Then give your more long detailed explanation and web links.

The new system suggests that we cannot do renaming to old interface names. Hence instead, can an automated check be made to find and *suggest* fixes to all affected config files?


I'll leave others to discuss whether we keep with the new static interface naming or offer an aliasing scheme whereby the static names can be also be referred to as for example enet0, enet1... (I'm leery of using "net0", "net1" etc because that naming commonly gets used elsewhere.)

Thanks,
Martin
Comment 68 William Hubbs gentoo-dev 2013-03-14 17:52:01 UTC
(In reply to comment #67)
> Sorry, I've not checked what whatever present warning messages are given
> before an update, but can this scenario be put in place as a fix:
> 
> Give a "dumb-speak" warning saying that the network interface names will be
> changed and this may break other system settings. Then give your more long
> detailed explanation and web links.

Can you please be more specific? Can you check the warnings and let us know what else you think we should add?

> The new system suggests that we cannot do renaming to old interface names.
> Hence instead, can an automated check be made to find and *suggest* fixes to
> all affected config files?

The problem here is that there is no simple way for us to cover *all* possible cases that I'm aware of.

> I'll leave others to discuss whether we keep with the new static interface
> naming or offer an aliasing scheme whereby the static names can be also be
> referred to as for example enet0, enet1... (I'm leery of using "net0",
> "net1" etc because that naming commonly gets used elsewhere.)

Unfortunately, the kernel doesn't and never has allowed a network interface to have more than one name, so there isn't a way to do an aliasing scheme.

Udev doesn't actually force you into this network naming scheme. All it does is set up a default naming policy and the documentation tells you how to change that.

The choices you have are covered in the

"I don't like this, how do I disable this?"

section of the wiki page referred to in comment #6.

The choice we made in udev 197 was affectively a version of option 1, but in 198 or newer, we are leaving it up to you.

The "why" section of the same wiki page explains the problems with users trying to rename interfaces within the old names, such as renaming eth1 to eth0. They explain why allowing this was dropped from udev (the kernel never allowed it, but udev had some extra code that made it happen).

Does that clarify things more?

William
Comment 69 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2013-03-14 20:40:29 UTC
williamh:
Clarification question, from the freedesktop page:
> This combined policy is only applied as last resort. That means, if the system
> has biosdevname installed, it will take precedence. If the user has added udev
> rules which change the name of the kernel devices these will take precedence
> too. Also, any distribution specific naming schemes generally take precedence.
With all rule files removed from /etc/, and the /lib ones stock, however, biosdevname does NOT get used.
I should have named my interfaces {em1,em2,p0p0,p0p1}.
Yet it wants to name them {enp{4,8}s0,enp11s0f{0,1}} (per net-name-test).
Comment 70 Samuli Suominen (RETIRED) gentoo-dev 2013-03-14 20:58:38 UTC
(In reply to comment #69)
> williamh:
> Clarification question, from the freedesktop page:
> > This combined policy is only applied as last resort. That means, if the system
> > has biosdevname installed, it will take precedence. If the user has added udev
> > rules which change the name of the kernel devices these will take precedence
> > too. Also, any distribution specific naming schemes generally take precedence.
> With all rule files removed from /etc/, and the /lib ones stock, however,
> biosdevname does NOT get used.
> I should have named my interfaces {em1,em2,p0p0,p0p1}.
> Yet it wants to name them {enp{4,8}s0,enp11s0f{0,1}} (per net-name-test).

Right, that's why postinst message of udev says biosdevname is deprecated in favour of the predictable network names
Comment 71 William Hubbs gentoo-dev 2013-03-14 22:03:15 UTC
(In reply to comment #70)
> (In reply to comment #69)
> > williamh:
> > Clarification question, from the freedesktop page:
> > > This combined policy is only applied as last resort. That means, if the system
> > > has biosdevname installed, it will take precedence. If the user has added udev
> > > rules which change the name of the kernel devices these will take precedence
> > > too. Also, any distribution specific naming schemes generally take precedence.
> > With all rule files removed from /etc/, and the /lib ones stock, however,
> > biosdevname does NOT get used.
> > I should have named my interfaces {em1,em2,p0p0,p0p1}.
> > Yet it wants to name them {enp{4,8}s0,enp11s0f{0,1}} (per net-name-test).

@ssuominen:
I just walked through this with @robbat2, and if biosdevname is installed, udev does use the biosdevname rules since they are installed as
/lib/udev/71-biosdevname.rules. You see this by looking at both stderr and stdout from:

udevadm test /sys/class/net/<ifname>

> Right, that's why postinst message of udev says biosdevname is deprecated in
> favour of the predictable network names

I think this should be removed since udev doesn't stop you from using biosdevname.
Comment 72 William Hubbs gentoo-dev 2013-03-14 22:30:14 UTC
Created attachment 342056 [details]
net-name-test.sh

Here is an updated net-name-test.sh.
This one actually shows you the name your interface will get and the
location of the rule that name comes from.
Comment 73 William Hubbs gentoo-dev 2013-03-15 05:43:15 UTC
Created attachment 342068 [details]
net-name-test.sh

All, this is the version of net-name-test.sh you should use.
Be aware that it does not give accurate information if you have
biosdevname or anything else that uses RUN or PROGRAM options in the
udev rules to get the name of the network interfaces.

Thanks to @robbat2 for  testing.
Comment 74 Samuli Suominen (RETIRED) gentoo-dev 2013-03-15 08:12:51 UTC
(In reply to comment #71)
> > Right, that's why postinst message of udev says biosdevname is deprecated in
> > favour of the predictable network names
> I think this should be removed since udev doesn't stop you from using
> biosdevname.

It's a warning instead of hard blocker based on your logic already. There is no need to keep continuing to use biosdevname, and I'm considering moving it as a blocker in later udev ebuilds
The migration plan in Fedora includes replacing biosdevname with plain udev, too
Comment 75 Samuli Suominen (RETIRED) gentoo-dev 2013-03-15 08:17:11 UTC
http://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames

Scope:

"As part of this feature we also want to remove biosdevname from comps, so that it is not installed anymore for new installations."
Comment 76 William Hubbs gentoo-dev 2013-03-15 16:20:23 UTC
(In reply to comment #74)
> (In reply to comment #71)
> > > Right, that's why postinst message of udev says biosdevname is deprecated in
> > > favour of the predictable network names
> > I think this should be removed since udev doesn't stop you from using
> > biosdevname.
> 
> It's a warning instead of hard blocker based on your logic already. There is
> no need to keep continuing to use biosdevname, and I'm considering moving it
> as a blocker in later udev ebuilds
> The migration plan in Fedora includes replacing biosdevname with plain udev,
> too

Fedora isn't planning on forcing it to be removed from people's systems, just preventing new installations. If we make it a blocker that means it will be automatically removed from people's systems, so I disagree with that.

If we are going to deprecate biosdevname, I would rather just go through the lastrights procedure for it.
Comment 77 Igor Franchuk 2013-03-15 22:19:16 UTC
The solutions are all good but in real life renaming interfaces is the last thing  you want with remote a server. Even if you know what names interfaces will receive with a complex config the chances are that you won't boot or you may boot but parts of the system will not work. One may continue fixing the system for months after the update. 

It's far more reliable to restore the old udev behavior. Add a new configure option and let users think for themselves if they need the new behavior or not. Gentoo could use a new use flag. By default the udev will behave as the old one and the flag should be ON by default and if somebody meets with the imaginable problems mentioned in udev annotation he can turn this flag off and get a new udev sound and running in just what - a few months may be.  

This all story with udev is mimicking Windows 8 "successful" start. Ballmer was born when the coolest thing ever was the touch-screen. It was only in the SF movies like the Flight of the Navigator which he watched over and over again. And when he grew he got his chance to prove to the world that a touch interface is superior to the keyboard and everyone else with the keyboard are just old-fashioned pranks. Sometimes keyboard jams he says and ah... a few extra letters are printed he says, and then yes, you can spill tea on the keyboard, and in 10 000 years these extra letters will burn the LCD - let's fix these great problems because we have nothing else important to do with our lives but fixing things which are proved by time. Let's remove keyboard entirely that is what he says.

And the solution of this problem will be exactly the same as with windows 8. The udev should be rolled back and the users should decide what's best for them - a chance of their server being killed by a meteorite or an inevitable death by installing udev.
Comment 78 Mike Gilbert gentoo-dev 2013-03-15 23:55:27 UTC
(In reply to comment #77)

No ranting in bugzilla please. This is not a discussion forum.
Comment 79 Samuli Suominen (RETIRED) gentoo-dev 2013-03-17 17:49:49 UTC
*** Bug 462082 has been marked as a duplicate of this bug. ***
Comment 80 snowy.mail 2013-03-24 08:04:05 UTC
(In reply to comment #30)

Thanks for the renaming script.

However, in my case, it does not work every single time. Unfortunately, I am not able to reproduce the failure. What I have noticed, however, is that if my local server was off for several hours, the renaming fails; when I do a reboot, it is working again.

For my remote servers, this behavior could be really painful...

I agree to the upper part of comment #77, why not have a configuration option for the old behavior?
Comment 81 Sergey Popov gentoo-dev 2013-03-24 09:25:23 UTC
(In reply to comment #80)
> I agree to the upper part of comment #77, why not have a configuration
> option for the old behavior?

As we said before: because it's not possible due to upstream decision
Comment 82 Samuli Suominen (RETIRED) gentoo-dev 2013-03-24 09:35:47 UTC
(In reply to comment #80)
> (In reply to comment #30)
> 
> Thanks for the renaming script.
> 
> However, in my case, it does not work every single time. Unfortunately, I am
> not able to reproduce the failure. What I have noticed, however, is that if
> my local server was off for several hours, the renaming fails; when I do a
> reboot, it is working again.
> 
> For my remote servers, this behavior could be really painful...
> 
> I agree to the upper part of comment #77, why not have a configuration
> option for the old behavior?

Rename to free namespace like net0, net1, internet0, internet1, foobar0, foobar1, ... 
Or switch to the new predictable names which are now enabled by default for 198, soon-to-be 199, and live-ebuild 9999, then you don't need to rename at all since the names are predictable!

This is by design.

(In reply to comment #81)
> (In reply to comment #80)
> > I agree to the upper part of comment #77, why not have a configuration
> > option for the old behavior?
> 
> As we said before: because it's not possible due to upstream decision

Correct.
Comment 83 snowy.mail 2013-03-24 10:38:43 UTC
(In reply to comment #82)

I wouldn't mind new names for the devices, if this would not mean rewriting a bunch of configuration files, iptables skripts and so on on several servers.

Furthermore, for remote servers this transition is far too risky in my eyes, possibly resulting in a non-responding server. This is a risk I am not willing to take.
Comment 84 Martin 2013-03-25 21:28:24 UTC
(In reply to comment #53)
> (In reply to comment #39)
[...]
> Reboot saw the expected reshuffling of the network cards eth numbers... That
> was fixed by renumbering the eths in the Shorewall interfaces file and in
> the Gentoo net config /etc/conf.d/net to match.
> 
> 
> > So... How to fix this easily for existing users?
> 
> That's one machine... Hopefully, multi-nic machines are rare?

Well... That was a rhetorical question: I've got 6 more multi-nic servers to work through which is going to be very badly time consuming to fix a lot connected configs... And it all has to just simply work "first time".


Hence:

Is a naive 'dumb fix' of setting symlinks in /dev (eg "/dev/sdXN") to the respective new "persistent-net-names" workable?

Or would such /dev symlinks need to be replicated also in various other /dev /proc /sys trees?


Regards,
Martin
Comment 85 Martin 2013-03-25 21:32:14 UTC
(In reply to comment #84)

> Hence:
> 
> Is a naive 'dumb fix' of setting symlinks in /dev (eg "/dev/sdXN") to the
> respective new "persistent-net-names" workable?
> 
> Or would such /dev symlinks need to be replicated also in various other /dev
> /proc /sys trees?


"/dev/sdXN" should of course read "/dev/ethX" for this case...!

Regards,
Martin
Comment 86 Samuli Suominen (RETIRED) gentoo-dev 2013-03-26 07:27:20 UTC
(In reply to comment #85)
> (In reply to comment #84)
> 
> > Hence:
> > 
> > Is a naive 'dumb fix' of setting symlinks in /dev (eg "/dev/sdXN") to the
> > respective new "persistent-net-names" workable?
> > 
> > Or would such /dev symlinks need to be replicated also in various other /dev
> > /proc /sys trees?
> 
> 
> "/dev/sdXN" should of course read "/dev/ethX" for this case...!
> 
> Regards,
> Martin

There has never been /dev nodes for network interfaces. Or do you remember seeing things like /dev/eth0? Then that must have been some other UNIX like AIX, but not Linux -- although I have to admit I don't remember things from old kernels like Linux 2.0 or 2.2 from back in 90s, so please google for more accurate information.

And you can find out what the names will be using the script from Comment #73, but
you would have find that out by reading this bug...
Same information is in the "dummy" file /etc/udev/rules.d/80-net-name-slot.rules if it's still in place, and same information is in postinst message of >=sys-fs/udev-198 since we no longer install /etc/udev/rules.d/80-net-name-slot.rules

Basically you are asking the already asked questions again, and I'm answering to them again, they are all over this bug, the ebuild, the example file, the forums, referenced from the news item, etc etc

(I had no problems booting the 12 servers at work straight to the new names)
Comment 87 Martin 2013-03-26 09:18:42 UTC
(In reply to comment #86)
> (In reply to comment #85)
> > (In reply to comment #84)
> > 
> > > Hence:
> > > 
> > > Is a naive 'dumb fix' of setting symlinks in /dev ... "/dev/ethX"

> 
> There has never been /dev nodes for network interfaces. Or do you remember
> seeing things like /dev/eth0? Then that must have been some other UNIX like

Indeed so. For my case I was thinking of the /dev/net/tunXX on the system, but that's not for real physical hardware...


> And you can find out what the names will be using the script from Comment
> #73, but
> you would have find that out by reading this bug...
> Same information is in the "dummy" file
> /etc/udev/rules.d/80-net-name-slot.rules if it's still in place, and same
> information is in postinst message of >=sys-fs/udev-198 since we no longer
> install /etc/udev/rules.d/80-net-name-slot.rules

...And also needed with that is a right-first-time strategy to avoid service interruption for heavily used multi-service systems with eight ports each (eth0 - eth7 with eth:xxx 'aliases'). I'm hoping not to lose too much of the Easter break untangling that...


> Basically you are asking the already asked questions again, and I'm
> answering to them again, they are all over this bug, the ebuild, the example
> file, the forums, referenced from the news item, etc etc
> 
> (I had no problems booting the 12 servers at work straight to the new names)

And you've already answered that all the other non-udev configs affected (broken) cannot be allowed for by this change.

Good for your case and easy enough for single nic servers. However, go multi-nic and multi services referencing those nics and... This remains quite a headache.


Unfortunately, still difficult from all sides for existing multi-nic systems.
Comment 88 Martin 2013-03-26 10:03:25 UTC
(In reply to comment #87)

> multi-nic and multi services referencing those nics and... This remains

Unless anyone has any better ideas:

egrep -R 'eth[0-9]' /etc
Work through the list with sed ...
Wait until midnight (when hopefully noone is looking) and reboot...

Regards,
Martin
Comment 89 Samuli Suominen (RETIRED) gentoo-dev 2013-03-26 14:41:59 UTC
*** Bug 463296 has been marked as a duplicate of this bug. ***
Comment 90 Alexander Tsoy 2013-03-31 10:43:29 UTC
There are 2 internal network interfaces on my motherboard (this is a Supermicro server board). Initialy they was named enp1s0 and enp2s0.

01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

Then I install a video card, and interfaces got renamed to enp2s0 and enp3s0:

01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Cape Verde PRO [Radeon HD 7750]
01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Cape Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series]
02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

So predictable network names are not really predictable? :) Qote from the URL:

"With this new scheme you now get: 
...
- Stable interface names even when hardware is added or removed, i.e. no re-enumeration takes place
..."
Comment 91 Alex Efros 2013-03-31 11:02:14 UTC
(In reply to comment #90)
> So predictable network names are not really predictable? :) Qote from the
> URL:
> 
> "With this new scheme you now get: 
> ...
> - Stable interface names even when hardware is added or removed, i.e. no
> re-enumeration takes place
> ..."

BTW, I've same issue when I decide to enable more USB3.0 ports in BIOS (which was disabled because I've no USB3.0 devices and I try to avoid enabling hardware and software features which I don't need now).
Comment 92 Samuli Suominen (RETIRED) gentoo-dev 2013-03-31 14:03:32 UTC
(In reply to comment #90)
[ ... ]

Then use consistent names by renaming into eg. net0, net1, net2 based on MACs or use Option 4) directly from upstream wiki page that creates MAC based iface names
Multiple options to get sane setup, just pick one
:-)
Comment 93 and 2013-03-31 18:30:16 UTC
We take option 1) 
renaming interfaces based on MAC to non-kernel namespace interface names.

Where belongs these rules now, ideally?
In the old and "semi wrong" 70-persistent-net.rules?
In 80-net-name-slot.rules? 
Or in a custom rule file before or after 80-net-name-slot.rules?

On a new installed system, we will have a non-emtpy 80-net-name-slot.rules file, right?
So our renaming to non-kernel namespace rule should belongs after 
80-net-name-slot.rules file?
Comment 94 Samuli Suominen (RETIRED) gentoo-dev 2013-03-31 18:33:45 UTC
(In reply to comment #93)
> We take option 1) 
> renaming interfaces based on MAC to non-kernel namespace interface names.
> 
> Where belongs these rules now, ideally?
> In the old and "semi wrong" 70-persistent-net.rules?
> In 80-net-name-slot.rules? 
> Or in a custom rule file before or after 80-net-name-slot.rules?
> 
> On a new installed system, we will have a non-emtpy 80-net-name-slot.rules
> file, right?
> So our renaming to non-kernel namespace rule should belongs after 
> 80-net-name-slot.rules file?

You should only have _1_ file called, for example, 70-my-network.rules in /etc/udev/rules.d with content like:

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:85", NAME="net0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:fd", NAME="net1"

Adjust the MACs to match yours. Delete any 70-persistent-*.rules and 80-net-*.rules from /etc/udev/rules.d so they don't interfere with
this 70-my-network.rules you are creating.
Comment 95 eponymous 2013-04-03 10:16:43 UTC
Is it still a) possible b) recommended to use the rename rc-script attached to this bug alongside a valid 70-persistent-net.rules and 80-net-name-slot.rules if we want to keep "eth0" style naming?

I was holding off moving to a "MAC based re-name to net0" until I'm sure that it won't break anything that expects "eth0".

Thanks.
Comment 96 eponymous 2013-04-03 10:57:28 UTC
(In reply to comment #95)
> Is it still a) possible b) recommended to use the rename rc-script attached
> to this bug alongside a valid 70-persistent-net.rules and
> 80-net-name-slot.rules if we want to keep "eth0" style naming?
> 
> I was holding off moving to a "MAC based re-name to net0" until I'm sure
> that it won't break anything that expects "eth0".
> 
> Thanks.

Sorry I meant is it still relevant to udev 200 as I sucessfully set up the rename rc-script and rules files for udev 197 and don't know if it is still the recommended practice.
Comment 97 Samuli Suominen (RETIRED) gentoo-dev 2013-04-03 10:59:54 UTC
(In reply to comment #95)
> Is it still a) possible b) recommended to use the rename rc-script attached
> to this bug alongside a valid 70-persistent-net.rules and
> 80-net-name-slot.rules if we want to keep "eth0" style naming?
> 
> I was holding off moving to a "MAC based re-name to net0" until I'm sure
> that it won't break anything that expects "eth0".
> 
> Thanks.

Nothing should have changed in-between, but using the rc-script here was definetely never recommended, otherwise it would be in portage by now
Just use different namespace, like net* lan* internet* or you can even use names like etha, ethb, ethc, since kernel shouldn't reserve by letter I believe
Comment 98 Martin 2013-04-03 12:33:36 UTC
(In reply to comment #97)
> (In reply to comment #95)
> > Is it still a) possible b) recommended to use the rename rc-script attached
> > to this bug alongside a valid 70-persistent-net.rules and
> > 80-net-name-slot.rules if we want to keep "eth0" style naming?
> > 
> > I was holding off moving to a "MAC based re-name to net0" until I'm sure
> > that it won't break anything that expects "eth0".
> > 
> > Thanks.
> 
> Nothing should have changed in-between, but using the rc-script here was
> definetely never recommended, otherwise it would be in portage by now
> Just use different namespace, like net* lan* internet* or you can even use
> names like etha, ethb, ethc, since kernel shouldn't reserve by letter I
> believe

Just a check before losing any remote systems:

Can /etc/udev/rules.d/70-persistent-net.rules be used with interface names such as:

eth_0, eth_1, eth_2, etc...

or would those get tripped up anywhere?

Thanks,
Martin
Comment 99 Samuli Suominen (RETIRED) gentoo-dev 2013-04-03 13:13:34 UTC
(In reply to comment #98)
> (In reply to comment #97)
> > (In reply to comment #95)
> > > Is it still a) possible b) recommended to use the rename rc-script attached
> > > to this bug alongside a valid 70-persistent-net.rules and
> > > 80-net-name-slot.rules if we want to keep "eth0" style naming?
> > > 
> > > I was holding off moving to a "MAC based re-name to net0" until I'm sure
> > > that it won't break anything that expects "eth0".
> > > 
> > > Thanks.
> > 
> > Nothing should have changed in-between, but using the rc-script here was
> > definetely never recommended, otherwise it would be in portage by now
> > Just use different namespace, like net* lan* internet* or you can even use
> > names like etha, ethb, ethc, since kernel shouldn't reserve by letter I
> > believe
> 
> Just a check before losing any remote systems:
> 
> Can /etc/udev/rules.d/70-persistent-net.rules be used with interface names
> such as:
> 
> eth_0, eth_1, eth_2, etc...
> 
> or would those get tripped up anywhere?
> 
> Thanks,
> Martin

Don't use _ or other chars like -+, even if most of base system would somehow boot up with it, almost certainly something will fail! Just alphabets and numbers far as I can remember.
Comment 100 Samuli Suominen (RETIRED) gentoo-dev 2013-04-03 13:15:26 UTC
Plus, everyone, let's use http://forums.gentoo.org/ for thesetype of issues, please! Otherwise unrelated people will only get bugspam they don't need.