13.1 - why network eth0 is named instead ens33?

[Carlos E. R.]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



I installed 13.1 under vmplayer.

On second boot, there was no network, but rcnetwork started it.

However, the name is abusrd: ens33.

Where is eth0? Why the change?
How do I revert that change?

- --
Cheers,
Carlos E. R.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlJG5PsACgkQtTMYHG2NR9WG7gCfS3H16eYR4dyzeMWGV6K3RID1
SgIAnR/zBAXAHnIS8gbSJlXgk9OikpLx
=PudE
-----END PGP SIGNATURE-----

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

В Sat, 28 Sep 2013 16:17:23 +0200 (CEST)

Post by Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I installed 13.1 under vmplayer.
On second boot, there was no network, but rcnetwork started it.
However, the name is abusrd: ens33.

What makes ens33 more absurd than eth0?

Post by Carlos E. R.
Where is eth0? Why the change?
How do I revert that change?

One possibility is to add net.ifnames=0 to kernel command line.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlJG6QQACgkQR6LMutpd94w5+wCfbbSactelobHowtOr1p/qKP2d
eyEAnjTFZCcQl7OUssU/kjDJn46lzbU1
=6BPc
-----END PGP SIGNATURE-----
Х╨{.nг+┴╥·≥╗╔╒≈╖╡К}╖-╒╪╬╨{.nг+┴╥╗╔ИЛ╨г╗╝

[Carlos E. R.]

Post by Andrey Borzenkov

Post by Carlos E. R.
However, the name is abusrd: ens33.

What makes ens33 more absurd than eth0?

How about 20 years of tradition?

Post by Andrey Borzenkov

Post by Carlos E. R.
Where is eth0? Why the change?
How do I revert that change?

One possibility is to add net.ifnames=0 to kernel command line.

I'll try.

- --
Cheers,
Carlos E. R.
(from 12.3 x86_64 "Dartmouth" at Telcontar)

[Greg KH]

Post by Carlos E. R.

Post by Andrey Borzenkov

Post by Carlos E. R.
However, the name is abusrd: ens33.

What makes ens33 more absurd than eth0?

How about 20 years of tradition?

Sometimes tradition is wrong for modern things.

Like systems where I can yank out any network device and add new ones
while the machine runs, old-style Unix machines could not do that.

[Hans Witvliet]

From: Carlos E. R. <***@telefonica.net>
To: OS-fctry <opensuse-***@opensuse.org>
Subject: Re: [opensuse-factory] 13.1 - why network eth0 is named instead
ens33?
Date: Sat, 28 Sep 2013 17:08:21 +0200 (CEST)

Post by Andrey Borzenkov

Post by Carlos E. R.
However, the name is abusrd: ens33.

What makes ens33 more absurd than eth0?

How about 20 years of tradition?

-----Original Message-----

How about: God knows how many addon-scripts expect network devices to be named ethXX

[Felix Miata]

Post by Andrey Borzenkov
What makes ens33 more absurd than eth0?

Eth0 is easily recognizable by all familiar with traditional networking,
without eidedic memory, and without requiring a lookup table.

Maximum predictability here means every installation under the same roof uses
the same name for the first (and only) *E*T*H*ernet port for it's reserved IP
address.

Post by Andrey Borzenkov
One possibility is to add net.ifnames=0 to kernel command line.

When? On every boot? Only on boots on which zypper or yast will be installing
updates? Only at initial installation? Does it need to be in
/etc/sysconfig/bootloader too?
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/

[Cristian Rodríguez]

Post by Felix Miata
When? On every boot? Only on boots on which zypper or yast will be
installing updates? Only at initial installation? Does it need to be in
/etc/sysconfig/bootloader too?

To be permanent..yes. you need to add it to the bootloader parameters.

[Felix Miata]

[re: add net.ifnames=0 to kernel command line]

Post by Cristian Rodríguez

Post by Felix Miata
When? On every boot? Only on boots on which zypper or yast will be
installing updates? Only at initial installation? Does it need to be in
/etc/sysconfig/bootloader too?

To be permanent..yes. you need to add it to the bootloader parameters.

Good to know, but not an answer I wanted to hear.

I'm giving a simpler approach a try. I've just welded a copy of 12.3's
/etc/udev/rules.d/70-persistent-net.rules into one host's 13.1b1 / filesystem
with chattr.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/

[Per Jessen]

Post by Felix Miata
[re: add net.ifnames=0 to kernel command line]

Post by Cristian Rodríguez

Post by Felix Miata
When? On every boot? Only on boots on which zypper or yast will be
installing updates? Only at initial installation? Does it need to be
in /etc/sysconfig/bootloader too?

To be permanent..yes. you need to add it to the bootloader
parameters.

Good to know, but not an answer I wanted to hear.
I'm giving a simpler approach a try. I've just welded a copy of 12.3's
/etc/udev/rules.d/70-persistent-net.rules into one host's 13.1b1 /
filesystem with chattr.

Apparently, having an empty file called :

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

will also work. I have also been told that giving the network
interfaces names with YaST will work. I'm about to try that.

[Paul Thompson]

Carlos,

Post by Carlos E. R.
On second boot, there was no network, but rcnetwork started it.
However, the name is abusrd: ens33.
Where is eth0?

By default systemd now names interfaces using firmware/BIOS provided
index numbers (e.g. eno1), but if that info is not available (possibly
because you're inside vmplayer) it falls back to naming after
firmware/BIOS provided PCI-E hotplug slot index numbers -- which is what
you're seeing here.

Post by Carlos E. R.
Why the change?

It's in order to ensure *predictable* NIC names across reboots.

Post by Carlos E. R.
How do I revert that change?

You could disable the udev rule with something like:
`ln -sv /dev/null /etc/udev/rules.d/80-net-name-slot.rules`


Regards,

[Carlos E. R.]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Paul Thompson
Carlos,

Post by Carlos E. R.
On second boot, there was no network, but rcnetwork started it.
However, the name is abusrd: ens33.
Where is eth0?

By default systemd now names interfaces using firmware/BIOS provided
index numbers (e.g. eno1), but if that info is not available (possibly
because you're inside vmplayer) it falls back to naming after
firmware/BIOS provided PCI-E hotplug slot index numbers -- which is what
you're seeing here.

Post by Carlos E. R.
Why the change?

It's in order to ensure *predictable* NIC names across reboots.

My computers have been reliably using eth0 for decades.

This computer has two nics, and eth0 has always been eth0, and eth1 has
always been eth1.


For instance, now a script that used eth0 would have to be edited for each
computer.

Post by Paul Thompson

Post by Carlos E. R.
How do I revert that change?

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

I'll have a look.

- --
Cheers,
Carlos E. R.
(from 12.3 x86_64 "Dartmouth" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlJG8g0ACgkQtTMYHG2NR9U0hgCfVjltMkOLtfEo98beIu+b08d0
SGEAnjX9i6BhRe1AgSxREJ68D+FwI8PQ
=N2XE
-----END PGP SIGNATURE-----

[Cristian Rodríguez]

Post by Carlos E. R.

Post by Paul Thompson
It's in order to ensure *predictable* NIC names across reboots.

My computers have been reliably using eth0 for decades.

argumentum ad antiquitatem that is called.

Post by Carlos E. R.
For instance, now a script that used eth0 would have to be edited for
each computer.

The script is well.. wrong..making asumptions about interface names.

[Jan Engelhardt]

Post by Cristian Rodríguez

Post by Carlos E. R.
For instance, now a script that used eth0 would have to be edited for
each computer.

The script is well.. wrong..making asumptions about interface names.

It is not an assumption, it is just... a static way of configuration. :)

[Ken Schneider - openSUSE]

Post by Cristian Rodríguez

Post by Carlos E. R.

Post by Paul Thompson
It's in order to ensure *predictable* NIC names across reboots.

My computers have been reliably using eth0 for decades.

argumentum ad antiquitatem that is called.

Post by Carlos E. R.
For instance, now a script that used eth0 would have to be edited for
each computer.

The script is well.. wrong..making asumptions about interface names.

But there was no guess work as the ethernet interface was always called...

eth0

so the script was always right.

[Lew Wolfgang]

Post by Cristian Rodríguez

Post by Carlos E. R.

Post by Paul Thompson
It's in order to ensure *predictable* NIC names across reboots.

My computers have been reliably using eth0 for decades.

argumentum ad antiquitatem that is called.

Post by Carlos E. R.
For instance, now a script that used eth0 would have to be edited for
each computer.

The script is well.. wrong..making asumptions about interface names.

How would one make reference to the third Ethernet interface in a
box that has five? You have to call it something, and changing the
name without good reason sounds like something for-profit operating
systems would do.

Or, are you saying that we should never need to refer to a network interface
by name? That referring to it by IP address should be enough? But what
about interfaces without IP addresses, such as /dev/rst0?

Wouldn't it be possible to make the "ethX" names predictable across
reboots? Or am I missing something?

Regards,
Lew

[Jan Engelhardt]

Post by Lew Wolfgang
Or, are you saying that we should never need to refer to a network interface
by name? That referring to it by IP address should be enough?

The point is that any name (network interfaces or device nodes)
could already be a name that the user has statically assigned
overruling any default system decisions.

Post by Lew Wolfgang
But what about interfaces without IP addresses, such as /dev/rst0?

Since no single identifier works for all people in all cases, that is
why there is the possibility to pick them out in multiple ways.
Serial number, Make&Model, PCI/USB "path", ...

Post by Lew Wolfgang
Wouldn't it be possible to make the "ethX" names predictable across
reboots?

Yes, define some static user-endorsed rule like those the systems
has so far (in openSUSE) created for us in 70-persistent-net.rules.

[James Knott]

Post by Jan Engelhardt

Post by Lew Wolfgang
But what about interfaces without IP addresses, such as /dev/rst0?

Since no single identifier works for all people in all cases, that is
why there is the possibility to pick them out in multiple ways.
Serial number, Make&Model, PCI/USB "path", ...

Well, eth has worked well for years, as it identifies a physical device,
independent of protocol

[Cristian Rodríguez]

Post by Lew Wolfgang
How would one make reference to the third Ethernet interface in a
box that has five? You have to call it something, and changing the
name without good reason sounds like something for-profit operating
systems would do.
Or, are you saying that we should never need to refer to a network interface
by name?

No, I am not. what I'm trying to say is that there must be a simple way
to determine the needed interface name dynamically.

Post by Lew Wolfgang
Or am I missing something?

YEs, please read this
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
carrefully, particulary the "WHY?" section.

[Lew Wolfgang]

Post by Cristian Rodríguez

Post by Lew Wolfgang
How would one make reference to the third Ethernet interface in a
box that has five? You have to call it something, and changing the
name without good reason sounds like something for-profit operating
systems would do.
Or, are you saying that we should never need to refer to a network interface
by name?

No, I am not. what I'm trying to say is that there must be a simple way
to determine the needed interface name dynamically.

Post by Lew Wolfgang
Or am I missing something?

YEs, please read this
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
carrefully, particulary the "WHY?" section.

Thanks, that does make sense. I still remember the SunOS 3.3 days
where SCSI disks and tapes were named according to their SCSI
bus addresses, which were hardware switch selectable. At some
point after that the notion (from the Pea Sea world I think) that
hardware addressing should be randomized at boot was introduced.
Boy, did THAT ever suck!

Regards,
Lew

[Carlos E. R.]

Post by Cristian Rodríguez

Post by Carlos E. R.

Post by Paul Thompson
It's in order to ensure *predictable* NIC names across reboots.

My computers have been reliably using eth0 for decades.

argumentum ad antiquitatem that is called.

Post by Carlos E. R.
For instance, now a script that used eth0 would have to be edited for
each computer.

The script is well.. wrong..making asumptions about interface names.

What about openSUSE documentation? The firewall script is full of
references to eth0, eth1... and that's the only file I looked at yet.

- --
Cheers,
Carlos E. R.
(from 12.3 x86_64 "Dartmouth" at Telcontar)

[Cristian Rodríguez]

Post by Paul Thompson
By default systemd now names interfaces using firmware/BIOS provided
index numbers (e.g. eno1),

To be precise, it is udev that does that.

[Sid Boyce]

One cause is that /etc/udev/rules.d/70-persistent.net is missing as
happend on this box.
You can set them up appriately with the MAC addresses in the order you
require.
# cat /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="50:e5:49:c8:2e:8c", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:1c:f0:5b:65:5a", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:0e:2e:f1:36:99", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="wlan0"
Regards
Sid.

Post by Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I installed 13.1 under vmplayer.
On second boot, there was no network, but rcnetwork started it.
However, the name is abusrd: ens33.
Where is eth0? Why the change?
How do I revert that change?
- -- Cheers,
Carlos E. R.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlJG5PsACgkQtTMYHG2NR9WG7gCfS3H16eYR4dyzeMWGV6K3RID1
SgIAnR/zBAXAHnIS8gbSJlXgk9OikpLx
=PudE
-----END PGP SIGNATURE-----

[James Knott]

Post by Sid Boyce
One cause is that /etc/udev/rules.d/70-persistent.net is missing as
happend on this box.
You can set them up appriately with the MAC addresses in the order you
require.
# cat /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="50:e5:49:c8:2e:8c", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:1c:f0:5b:65:5a", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:0e:2e:f1:36:99", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="wlan0"

Is it my imagination, or is it the purpose of all these changes to make
administration more difficult? I have also been running Linux for
several years and never had a problem with NIC ID, at least with up to 3
NICs. In my experience, the ID depends on the slot the NIC is plugged
into. According to the above, changing a NIC will require editing a
file, to ensure the same ID is used.

[James Knott]

Post by James Knott
Is it my imagination, or is it the purpose of all these changes to make
administration more difficult? I have also been running Linux for
several years and never had a problem with NIC ID, at least with up to 3
NICs. In my experience, the ID depends on the slot the NIC is plugged
into. According to the above, changing a NIC will require editing a
file, to ensure the same ID is used.

Further on this. The computer with 3 NICs is my firewall. It has a
built in NIC and I added 2 more NICs. As originally configured with the
3 NICs., the plug in NICs were eth 0 & 1 and the built in one eth2. I
later removed eth1, because it was failing. But doing that did not
cause the other NIC IDs to change. I now have eth0 and eth2, with no
eth1 in the computer at all.

[Sid Boyce]

Post by James Knott

Post by Sid Boyce
One cause is that /etc/udev/rules.d/70-persistent.net is missing as
happend on this box.
You can set them up appriately with the MAC addresses in the order you
require.
# cat /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="50:e5:49:c8:2e:8c", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:1c:f0:5b:65:5a", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:0e:2e:f1:36:99", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="wlan0"

Is it my imagination, or is it the purpose of all these changes to make
administration more difficult? I have also been running Linux for
several years and never had a problem with NIC ID, at least with up to 3
NICs. In my experience, the ID depends on the slot the NIC is plugged
into. According to the above, changing a NIC will require editing a
file, to ensure the same ID is used.

I agree.
After doing an upgrades via zypper dup I noticed there was a change to
ens65 or something like that but only on one of 3 boxes.
The other 2 boxes still had /etc/udev/rules.d/70-persistent.net present.
Regards
Sid.

[Per Jessen]

Post by Sid Boyce

Post by James Knott

Post by Sid Boyce
One cause is that /etc/udev/rules.d/70-persistent.net is missing as
happend on this box.
You can set them up appriately with the MAC addresses in the order
you require.
# cat /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="50:e5:49:c8:2e:8c", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:1c:f0:5b:65:5a", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:0e:2e:f1:36:99", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="wlan0"

Is it my imagination, or is it the purpose of all these changes to
make administration more difficult? I have also been running Linux
for several years and never had a problem with NIC ID, at least with
up to 3 NICs. In my experience, the ID depends on the slot the NIC
is plugged into. According to the above, changing a NIC will require
editing a file, to ensure the same ID is used.

I agree.
After doing an upgrades via zypper dup I noticed there was a change to
ens65 or something like that but only on one of 3 boxes.
The other 2 boxes still had /etc/udev/rules.d/70-persistent.net present.

Yes, on an update you should definitely be able to retain the existing
naming. I suggest you open a bugreport.

[Sid Boyce]

Post by Per Jessen

Post by Sid Boyce

Post by James Knott

Post by Sid Boyce
One cause is that /etc/udev/rules.d/70-persistent.net is missing as
happend on this box.
You can set them up appriately with the MAC addresses in the order
you require.
# cat /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="50:e5:49:c8:2e:8c", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:1c:f0:5b:65:5a", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:0e:2e:f1:36:99", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="wlan0"

Is it my imagination, or is it the purpose of all these changes to
make administration more difficult? I have also been running Linux
for several years and never had a problem with NIC ID, at least with
up to 3 NICs. In my experience, the ID depends on the slot the NIC
is plugged into. According to the above, changing a NIC will require
editing a file, to ensure the same ID is used.

I agree.
After doing an upgrades via zypper dup I noticed there was a change to
ens65 or something like that but only on one of 3 boxes.
The other 2 boxes still had /etc/udev/rules.d/70-persistent.net present.

Yes, on an update you should definitely be able to retain the existing
naming. I suggest you open a bugreport.

I shall leave as is for now as I created
/etc/udev/rules.d/70-persistent.net on the one box where it was missing,
subsequent updates have not changed it.
Regards
Sid.

[Per Jessen]

Post by Carlos E. R.
I installed 13.1 under vmplayer.
On second boot, there was no network, but rcnetwork started it.
However, the name is abusrd: ens33.

Agree.

Post by Carlos E. R.
Where is eth0? Why the change?
How do I revert that change?

See https://bugzilla.novell.com/show_bug.cgi?id=820589

[Carlos E. R.]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Per Jessen

Post by Carlos E. R.
However, the name is abusrd: ens33.

Agree.

Post by Carlos E. R.
Where is eth0? Why the change?
How do I revert that change?

See https://bugzilla.novell.com/show_bug.cgi?id=820589

Mmmm.

- --
Cheers,
Carlos E. R.
(from 12.3 x86_64 "Dartmouth" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlJHih0ACgkQtTMYHG2NR9UN4QCffgOUN7Ijzt4d0kySDzCFMqJ8
71wAn04zTBYTXwOd4EE65+K6DwRGZDGu
=D6mX
-----END PGP SIGNATURE-----

[Per Jessen]

Post by Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I installed 13.1 under vmplayer.
On second boot, there was no network, but rcnetwork started it.
However, the name is abusrd: ens33.
Where is eth0? Why the change?
How do I revert that change?

Somwhat tangential to Carlos' question here, but any chance that anyone
would want to take a look at

https://bugzilla.novell.com/show_bug.cgi?id=842450

The networking naming isn't exactly consistent. Sometimes something is
renamed, sometimes not.