Discussion? New names of betwork devices

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Discussion? New names of betwork devices

Hans-J. Ullrich
Hi folks,

since some time the names for network devices have changed. So its is no more
"ethX" , but "enp1s10" or similar or "wlan0" and now "wlp5s0". You know, what
I mean.

This is made by the kernel.

However, I discovered many packages, where are still the old names
preconfigured with the old names. I think, this may be led to confusion, so let
me offer some suggestions:

- during installation there should be an advice, to check the name of the
interface

or

- interface entries should be generally commented, so that the user has
forcedly to check the entry

or

- preconfigure (and repreconfigure) configs, which are preinstalled with the new
names

I know, the last one might be problematic, because the developer never can
know, whhich interface is used (eth0? eth1? wlan0? whatever)

For myself I got the solution: just edited all configs to the new names, but I
believe, for unexperienced users, this could be problematic. And I also
believe, an unexperienced user gets in trouble, when nobody points him, where
to look.

You do not need to look for a solution for me, I just wanted to remember this
thing and hope, we should keep this little problem in mind. Maybe this is
worth a discussion, if not, please excuse the noise.

Best regards

Hans

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Discussion? New names of betwork devices

Reco
        Hi.

On Fri, Mar 22, 2019 at 04:06:33PM +0100, Hans wrote:
> Hi folks,
>
> since some time the names for network devices have changed. So its is no more
> "ethX" , but "enp1s10" or similar or "wlan0" and now "wlp5s0". You know, what
> I mean.

Yep, so called Unpredicable Device Names.


> This is made by the kernel.

No, this is done by udev. It can be disabled, it can be configured, and
it can be left as is.


> However, I discovered many packages, where are still the old names
> preconfigured with the old names.

Some examples are in order.


> I think, this may be led to confusion, so let
> me offer some suggestions:
>
> - during installation there should be an advice, to check the name of the
> interface

File a "wishlist" bug report against an appropriate package.


> - interface entries should be generally commented, so that the user has
> forcedly to check the entry

Most of the server-side packages that I can think of are either bind to all
available interfaces by default, or bind to lo, which is still here.


> I know, the last one might be problematic, because the developer never can
> know, whhich interface is used (eth0? eth1? wlan0? whatever)

Or, for instance, en0p2gibberish. They call them Unpredictable Device
Named for a reason.


> For myself I got the solution: just edited all configs to the new names, but I
> believe, for unexperienced users, this could be problematic.

So-called "unexperienced" users should not meddle in servers'
configuration in the first place.
And NIC configuration is hardly relevant for a typical desktop.


> And I also believe, an unexperienced user gets in trouble, when nobody
> points him, where to look.

I don't know about that. I mean, you wrote here, isn't it? Nobody's
stopping this hypothetical "unexperienced" users to do the same.


> You do not need to look for a solution for me, I just wanted to remember this
> thing and hope, we should keep this little problem in mind. Maybe this is
> worth a discussion, if not, please excuse the noise.

That's OK. It's Friday and it's been an eventful week, so a list can use
a flamewar.

Reco

Reply | Threaded
Open this post in threaded view
|

Re: Discussion? New names of betwork devices

Hans-J. Ullrich
Am Freitag, 22. März 2019, 17:15:29 CET schrieb Reco:
> Hi.
Hi Reco,
>
> No, this is done by udev. It can be disabled, it can be configured, and
> it can be left as is.
>
I know, that the old style can be kept by either using udev (withg persistent-
net.rules for example) or by a kernel parm (something like "ifnet.rename=0, or
similar, forgot the correct syntax)

> > However, I discovered many packages, where are still the old names
> > preconfigured with the old names.
>
> Some examples are in order.
>
I had to correct /etc/network/interfaces, kismet, wicd-*, powertweak, snort
and some others. No big deal.

>
> Most of the server-side packages that I can think of are either bind to all
> available interfaces by default, or bind to lo, which is still here.

There were more the desktop users with laptops in my mind.

>
> > I know, the last one might be problematic, because the developer never can
> > know, whhich interface is used (eth0? eth1? wlan0? whatever)
>
> Or, for instance, en0p2gibberish. They call them Unpredictable Device
> Named for a reason.
>

Yes, thsis is another thing, which I am thinking of: The names could change
(in case, when there are more than one network devices are active or the order
of activing changed). In the past, I forced the order with persistent-
net.rules. Dunno, if normal users can deal with it. Can it your Mom or your
Dad? Grandpa? Grandma?
 

> > For myself I got the solution: just edited all configs to the new names,
> > but I believe, for unexperienced users, this could be problematic.
>
> So-called "unexperienced" users should not meddle in servers'
> configuration in the first place.
> And NIC configuration is hardly relevant for a typical desktop.
>
> > And I also believe, an unexperienced user gets in trouble, when nobody
> > points him, where to look.
>
> I don't know about that. I mean, you wrote here, isn't it? Nobody's
> stopping this hypothetical "unexperienced" users to do the same.
Remember, this list is in English, not all people do speak English well
(included myself), and I doubt, most people want to spare the time, to crawl
through all the lists. They want it just work.
>
> > You do not need to look for a solution for me, I just wanted to remember
> > this thing and hope, we should keep this little problem in mind. Maybe
> > this is worth a discussion, if not, please excuse the noise.
>
> That's OK. It's Friday and it's been an eventful week, so a list can use
> a flamewar.
>

No, a flamewar will be funny for some people, but IMO it has got not much
worth. For myself, I can only tell: Upredictable Device Name is nice, but only
a good idea for specialists. But this is my opinion, and no one is forced, to
take it over.

Happy hacking and a nice weekend!

> Reco


Best

Hans

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Discussion? New names of betwork devices

Reco
On Fri, Mar 22, 2019 at 05:40:43PM +0100, Hans wrote:
> Am Freitag, 22. März 2019, 17:15:29 CET schrieb Reco:
> > No, this is done by udev. It can be disabled, it can be configured, and
> > it can be left as is.
> >
> I know, that the old style can be kept by either using udev (withg persistent-
> net.rules for example) or by a kernel parm (something like "ifnet.rename=0, or
> similar, forgot the correct syntax)

They did confuse you. All this renaming is done by udev.
Kernel does not need "net.ifnames" at all as it names network interfaces
in the first place.
Udev abuses kernel commandline do grab "net.ifnames", and then udev's rules
check the parameter.


> > > However, I discovered many packages, where are still the old names
> > > preconfigured with the old names.
> >
> > Some examples are in order.
> >
> I had to correct /etc/network/interfaces,

User-written by definition.

> kismet,

Yep, that's valid. I prefer aircrack-ng though.


> wicd-*,

Probably. ifupdown is more than enough for me (that includes 802.11x),
but don't they give a GUI for wicd?


> powertweak,

[1]. Is it a Debian package at all?


> snort

Comes with debconf and interface detection as far I can see it.
But I accept this particular one for the sake of simplicity.


> > Most of the server-side packages that I can think of are either bind to all
> > available interfaces by default, or bind to lo, which is still here.
>
> There were more the desktop users with laptops in my mind.

Does not invalidate my point. One can install a server package on a
laptop if a need arises. I have nginx installed on my *phone* because
it's convenient, for instance.


> > > I know, the last one might be problematic, because the developer never can
> > > know, whhich interface is used (eth0? eth1? wlan0? whatever)
> >
> > Or, for instance, en0p2gibberish. They call them Unpredictable Device
> > Named for a reason.
> >
>
> Yes, thsis is another thing, which I am thinking of: The names could change
> (in case, when there are more than one network devices are active or the order
> of activing changed).

Long story short, they invented Unpredictable Device Names to prevent
this very scenario.
I'm aware of one major case when it failed miserably (VMWare), and two
minor ones (renaming didn't happen for virtio, and cannot be configured
for USB devices).


> In the past, I forced the order with persistent-> net.rules. Dunno, if
> normal users can deal with it.

I don't hold by breath.


> > > For myself I got the solution: just edited all configs to the new names,
> > > but I believe, for unexperienced users, this could be problematic.
> >
> > So-called "unexperienced" users should not meddle in servers'
> > configuration in the first place.
> > And NIC configuration is hardly relevant for a typical desktop.
> >
> > > And I also believe, an unexperienced user gets in trouble, when nobody
> > > points him, where to look.

They have this list here. They have LUGs. They have
serverfault/stackoverflow (I know, it's a bad manners to mention
*these*).
Last, but not least, there's paid support.


> > I don't know about that. I mean, you wrote here, isn't it? Nobody's
> > stopping this hypothetical "unexperienced" users to do the same.
>
> Remember, this list is in English, not all people do speak English well
> (included myself),

Ditto. But this list is where all the fun happens, so I hang here.
And yes, it has surprising variance of questions.


> and I doubt, most people want to spare the time, to crawl
> through all the lists. They want it just work.

If one desires that one should pay someone who can actually force a
device do the job.
No amount of pre-configuration can change that. Even if we're
considering M$/Apple.


Reco

[1] https://packages.debian.org/search?searchon=names&suite=all&section=all&sourceid=mozilla-search&keywords=powertweak

Reply | Threaded
Open this post in threaded view
|

Re: Discussion? New names of betwork devices

ghe-2
In reply to this post by Hans-J. Ullrich
On 3/22/19 9:06 AM, Hans wrote:

> since some time the names for network devices have changed. So its is no more
> "ethX" , but "enp1s10" or similar or "wlan0" and now "wlp5s0". You know, what
> I mean.

Interesting that this came up this morning. I'm on Buster.alpha5. I
tried to relabel my Ethernet interfaces the eth<n> names a few days ago.
It didn't seem to work, so I tried to undo everything I'd done. This
morning, after another reboot, it came up with the eth<n> names.

The powers that be are calling my Ethernet devices enp6s0 and enp7s0. I
guess enp (EtherNet Port) is OK. But 6 and 7 aren't. There are only two
of them, and numbers on my computers don't start at 6.

Another suggestion:

The front panel of my Juniper firewall has a row of Ethernet ports
across it. It calls all of those ethernet0/<n>. Ethernet ports in the
plugins in the back start at ethernet1/<n>.

Eth sounds good to me, as long as nothing non-Ethernet is labeled eth.
But Juniper's naming algorithm makes a lot of sense. The connectors on
the motherboard could be called eth0<n>. And added boards could be eth1,
2, 3, etc.

> This is made by the kernel.

Not in Buster.alphs5, it ain't. The naming is quite complex, and there
are several files that've been chattr'ed so they cant be changed.

> However, I discovered many packages, where are still the old names
> preconfigured with the old names.

Change them to check the Ethernet port labels? I suspect that'd be
fairly easy for the Debian maintainers.

But udev can do all this well and nicely, if people'd just leave it
alone and let it do its job. And make sure things use the correct device
labels.

--
Glenn English

Reply | Threaded
Open this post in threaded view
|

Re: Discussion? New names of betwork devices

Joe Rowan
On Fri, 22 Mar 2019 13:53:33 -0600
ghe <[hidden email]> wrote:

>
> The powers that be are calling my Ethernet devices enp6s0 and enp7s0.
> I guess enp (EtherNet Port) is OK. But 6 and 7 aren't. There are only
> two of them, and numbers on my computers don't start at 6.

The 'p' is for PCI, and they are numbered for their PCI bus position.
Hence the hope that the name will never change.

--
Joe

Reply | Threaded
Open this post in threaded view
|

Re: Discussion? New names of betwork devices

ghe-2
On 3/22/19 1:56 PM, Joe wrote:

> The 'p' is for PCI, and they are numbered for their PCI bus position.

That makes some sense.

But when I'm looking to connect a cable, the location of the port on the
outside of the box is much more useful to me than the address number on
the bus.

When writing software, though, the bus address becomes more important
than the location.

A labeling algorithm useful in both situations would be nice...

--
Glenn English

Reply | Threaded
Open this post in threaded view
|

Re: Discussion? New names of betwork devices

Felix Miata-3
ghe composed on 2019-03-22 16:14 (UTC-0600):

> But when I'm looking to connect a cable, the location of the port on the
> outside of the box is much more useful to me than the address number on
> the bus.

> When writing software, though, the bus address becomes more important
> than the location.

> A labeling algorithm useful in both situations would be nice...

IME, using net.ifnames=0, the motherboard NIC closer to an ATX power supply is
always eth0. With BTX I've never had two NICs, but have to suppose it would be
the opposite. I think PCI(e) resources flow the same direction, from CPU & PS/2
port end to last slot end.
--
Evolution as taught in public schools is religion, not science.

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

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

Reply | Threaded
Open this post in threaded view
|

Re: Discussion? New names of betwork devices

deloptes-2
Felix Miata wrote:

> IME, using net.ifnames=0, the motherboard NIC closer to an ATX power
> supply is always eth0. With BTX I've never had two NICs, but have to
> suppose it would be the opposite. I think PCI(e) resources flow the same
> direction, from CPU & PS/2 port end to last slot end.

interesting theory, but I must disappoint you that it is not true. Usually
it is from the left to the right. It has nothing to do with the ATX, except
if it would be on the left.
Thinking is good but knowing is better!

regards

Reply | Threaded
Open this post in threaded view
|

Re: Discussion? New names of betwork devices

Felix Miata-3
deloptes composed on 2019-03-23 07:29 (UTC+0100):

> Felix Miata wrote:

>> IME, using net.ifnames=0, the motherboard NIC closer to an ATX power
>> supply is always eth0. With BTX I've never had two NICs, but have to
>> suppose it would be the opposite. I think PCI(e) resources flow the same
>> direction, from CPU & PS/2 port end to last slot end.

> interesting theory, but I must disappoint you that it is not true. Usually
> it is from the left to the right. It has nothing to do with the ATX, except
> if it would be on the left.

What "if"? The ATX is on the left when looking at the rear from the rear with
the slot openings facing up. ghe wanted a frame of reference. I gave the ATX
position, CPU position and PS/2 port position as usual "left" references, and
last PCI slot as "right" reference. A BTX is to an ATX oppositely situated
adjacent to the last (if any) slot.
--
Evolution as taught in public schools is religion, not science.

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

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

Reply | Threaded
Open this post in threaded view
|

Re: Discussion? New names of betwork devices

Hans-J. Ullrich
In reply to this post by Reco
Hi folks,

interesting thing, I found this little article in internet:

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

So, it looks like, since systemd v197, all devicenames are now predictable by
udev.

If so (just an idea) packagers or developers may add a routine for the
installation, which may ask for the actual names of the devices in the system
and add them automatically into the configuration of the installing
application.

As these (the devicenames) will never change, also non experienced users have
to quarrel with the devicenames any more.

Just an idea, I do not know, how difficult it is, to write and add such a
routine into the installer as a script (I am no coder).

However, if one gets such a thing working, it can be used for EVERY package.
My idea is, to add a variable or a special keyword into the configuration file,
which will be automatically exchanged with the correct devicename.

Sorry, I can not do this myself (I am no coder, did I tell you?), just sharing
my ideas. Maybe someone think my ideas usefull. If not - just ignore them.

In this case I apologize for all the noise.

Have a nice weekend!

Best

Hans



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Discussion? New names of betwork devices

Mart van de Wege
In reply to this post by Hans-J. Ullrich
Hans <[hidden email]> writes:

> Am Freitag, 22. März 2019, 17:15:29 CET schrieb Reco:
>> Or, for instance, en0p2gibberish. They call them Unpredictable Device
>> Named for a reason.
>>
>
> Yes, thsis is another thing, which I am thinking of: The names could change
> (in case, when there are more than one network devices are active or the order
> of activing changed).

No. Changes in the activation order or the number of devices do not
matter. The naming scheme is based on what bus the devices are on and
what position on that bus they hold[1]. Once a name is assigned, unless
you plug the card into a different slot, you will get the same name
(note that this may not apply on hotplug architectures that don't assume
fixed slot positions, like USB).

It is the *old* way that lead to unpredictable renames unless you
implemented udev rules to hardcode names to e.g. MAC addresses.

> In the past, I forced the order with persistent- net.rules. Dunno, if
> normal users can deal with it. Can it your Mom or your Dad? Grandpa?
> Grandma?
>  
Is it any worse than expecting them to write a udev rule?

In the end it is a hard problem to solve because the Linux kernel does
dynamic enumeration of devices, so you either need a deterministic
algorithm to assign a name (ask the firmware) or a userspace workaround
in identifying the device (e.g. using udev rules, or using UUIDs in
/etc/fstab, etc).

Mart

[1] OK, not *entirely* true, it's based on what the firmware reports as
the device position (it used to be called 'biosdevname'. Don't know if
that still is the name in these (U)EFI times).

--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

Reply | Threaded
Open this post in threaded view
|

Re: Discussion? New names of betwork devices

Nicholas Geovanis-2
My 0.02€
It's interesting how this topic is so often resurrected. The first time we upgraded a RedHat server and the network interfaces were renamed, our supervisor was.....angered :-)
The issue is the order of enumeration of devices on a PCI bus. Even identical models of NIC at the same level of firmware will become ready in non-uniform ways. Temperature plays a role, etc. If the systemd designers (same as the udev guys, right?) made a mistake here, perhaps it was overreach.

On Sat, Mar 23, 2019, 1:20 PM Mart van de Wege <[hidden email]> wrote:
Hans <[hidden email]> writes:

> Am Freitag, 22. März 2019, 17:15:29 CET schrieb Reco:
>> Or, for instance, en0p2gibberish. They call them Unpredictable Device
>> Named for a reason.
>>
>
> Yes, thsis is another thing, which I am thinking of: The names could change
> (in case, when there are more than one network devices are active or the order
> of activing changed).

No. Changes in the activation order or the number of devices do not
matter. The naming scheme is based on what bus the devices are on and
what position on that bus they hold[1]. Once a name is assigned, unless
you plug the card into a different slot, you will get the same name
(note that this may not apply on hotplug architectures that don't assume
fixed slot positions, like USB).

It is the *old* way that lead to unpredictable renames unless you
implemented udev rules to hardcode names to e.g. MAC addresses.

> In the past, I forced the order with persistent- net.rules. Dunno, if
> normal users can deal with it. Can it your Mom or your Dad? Grandpa?
> Grandma?

Is it any worse than expecting them to write a udev rule?

In the end it is a hard problem to solve because the Linux kernel does
dynamic enumeration of devices, so you either need a deterministic
algorithm to assign a name (ask the firmware) or a userspace workaround
in identifying the device (e.g. using udev rules, or using UUIDs in
/etc/fstab, etc).

Mart

[1] OK, not *entirely* true, it's based on what the firmware reports as
the device position (it used to be called 'biosdevname'. Don't know if
that still is the name in these (U)EFI times).

--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

Reply | Threaded
Open this post in threaded view
|

Re: Discussion? New names of betwork devices

Nicholas Geovanis-2
I suppose I should add this. In datacenters of a certain size, when the network cabling leaves control of the OS administrators (yes, even the Wintel admins), network admins aren't there to make your life easier. You do it yourself.
I encountered the same issue with SAN admins a bit later over fiber cabling to my servers. If the OS adds complication you deal with it, even if you didn't have to before. You can argue that admins should have been explicitly configuring NICs with salt, cobbler, etc. We did.

On Sat, Mar 23, 2019, 2:30 PM Nicholas Geovanis <[hidden email]> wrote:
My 0.02€
It's interesting how this topic is so often resurrected. The first time we upgraded a RedHat server and the network interfaces were renamed, our supervisor was.....angered :-)
The issue is the order of enumeration of devices on a PCI bus. Even identical models of NIC at the same level of firmware will become ready in non-uniform ways. Temperature plays a role, etc. If the systemd designers (same as the udev guys, right?) made a mistake here, perhaps it was overreach.

On Sat, Mar 23, 2019, 1:20 PM Mart van de Wege <[hidden email]> wrote:
Hans <[hidden email]> writes:

> Am Freitag, 22. März 2019, 17:15:29 CET schrieb Reco:
>> Or, for instance, en0p2gibberish. They call them Unpredictable Device
>> Named for a reason.
>>
>
> Yes, thsis is another thing, which I am thinking of: The names could change
> (in case, when there are more than one network devices are active or the order
> of activing changed).

No. Changes in the activation order or the number of devices do not
matter. The naming scheme is based on what bus the devices are on and
what position on that bus they hold[1]. Once a name is assigned, unless
you plug the card into a different slot, you will get the same name
(note that this may not apply on hotplug architectures that don't assume
fixed slot positions, like USB).

It is the *old* way that lead to unpredictable renames unless you
implemented udev rules to hardcode names to e.g. MAC addresses.

> In the past, I forced the order with persistent- net.rules. Dunno, if
> normal users can deal with it. Can it your Mom or your Dad? Grandpa?
> Grandma?

Is it any worse than expecting them to write a udev rule?

In the end it is a hard problem to solve because the Linux kernel does
dynamic enumeration of devices, so you either need a deterministic
algorithm to assign a name (ask the firmware) or a userspace workaround
in identifying the device (e.g. using udev rules, or using UUIDs in
/etc/fstab, etc).

Mart

[1] OK, not *entirely* true, it's based on what the firmware reports as
the device position (it used to be called 'biosdevname'. Don't know if
that still is the name in these (U)EFI times).

--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

Reply | Threaded
Open this post in threaded view
|

Re: Discussion? New names of betwork devices

David Wright-3
In reply to this post by Felix Miata-3
On Sat 23 Mar 2019 at 04:39:21 (-0400), Felix Miata wrote:

> deloptes composed on 2019-03-23 07:29 (UTC+0100):
> > Felix Miata wrote:
>
> >> IME, using net.ifnames=0, the motherboard NIC closer to an ATX power
> >> supply is always eth0. With BTX I've never had two NICs, but have to
> >> suppose it would be the opposite. I think PCI(e) resources flow the same
> >> direction, from CPU & PS/2 port end to last slot end.
>
> > interesting theory, but I must disappoint you that it is not true. Usually
> > it is from the left to the right. It has nothing to do with the ATX, except
> > if it would be on the left.
>
> What "if"? The ATX is on the left when looking at the rear from the rear with
> the slot openings facing up. ghe wanted a frame of reference. I gave the ATX
> position, CPU position and PS/2 port position as usual "left" references, and
> last PCI slot as "right" reference. A BTX is to an ATX oppositely situated
> adjacent to the last (if any) slot.

How does this differ from a race condition?

Cheers,
David.

Reply | Threaded
Open this post in threaded view
|

Re: Discussion? New names of betwork devices

Felix Miata-3
David Wright composed on 2019-03-23 23:03 (UTC-0400):

> On Sat 23 Mar 2019 at 04:39:21 (-0400), Felix Miata wrote:

>> The ATX is on the left when looking at the rear from the rear with
>> the slot openings facing up. ghe wanted a frame of reference. I gave the ATX
>> position, CPU position and PS/2 port position as usual "left" references, and
>> last PCI slot as "right" reference. A BTX is to an ATX oppositely situated
>> adjacent to the last (if any) slot.

> How does this differ from a race condition?

???

Relative physical positions of motherboard components are for the motherboard's
entire life.

Time is an implicit element of every race.

Time can't change motherboard components' relative physical positions.
--
Evolution as taught in public schools is religion, not science.

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

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

Reply | Threaded
Open this post in threaded view
|

Re: Discussion? New names of betwork devices

deloptes-2
Felix Miata wrote:

> Time can't change motherboard components' relative physical positions.

this is true, but to conclude that the numbering of the ethernet devices
depends on the position of the ATX or whatever is a bit too much.
Naturally it is left to right when you look at the back.

regards

Reply | Threaded
Open this post in threaded view
|

Re: Discussion? New names of betwork devices

Felix Miata-3
deloptes composed on 2019-03-24 07:21 (UTC+0100):

> Felix Miata wrote:

>> Time can't change motherboard components' relative physical positions.

> this is true, but to conclude that the numbering of the ethernet devices
> depends on the position of the ATX or whatever is a bit too much.

Keyword: "IME". I never wrote anything about "depends". What I wrote was
starting from ATX power supply end of motherboard end is how it has (always)
been observed here when net.ifnames=0 is on the kernel cmdline.
--
Evolution as taught in public schools is religion, not science.

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

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

Reply | Threaded
Open this post in threaded view
|

Re: Discussion? New names of betwork devices

David Wright-3
In reply to this post by Felix Miata-3
On Sat 23 Mar 2019 at 23:29:07 (-0400), Felix Miata wrote:

> David Wright composed on 2019-03-23 23:03 (UTC-0400):
>
> > On Sat 23 Mar 2019 at 04:39:21 (-0400), Felix Miata wrote:
>
> >> The ATX is on the left when looking at the rear from the rear with
> >> the slot openings facing up. ghe wanted a frame of reference. I gave the ATX
> >> position, CPU position and PS/2 port position as usual "left" references, and
> >> last PCI slot as "right" reference. A BTX is to an ATX oppositely situated
> >> adjacent to the last (if any) slot.
>
> > How does this differ from a race condition?
>
> ???
>
> Relative physical positions of motherboard components are for the motherboard's
> entire life.
>
> Time is an implicit element of every race.
>
> Time can't change motherboard components' relative physical positions.

It takes two to shake hands: the time it takes to complete the
handshake depends on the cooperation or otherwise of the other
person. Same with mobos and NICs.

Cheers,
David.

Reply | Threaded
Open this post in threaded view
|

Re: Discussion? New names of betwork devices

David Wright-3
In reply to this post by Hans-J. Ullrich
On Fri 22 Mar 2019 at 17:40:43 (+0100), Hans wrote:
> Am Freitag, 22. März 2019, 17:15:29 CET schrieb Reco:

> > No, this is done by udev. It can be disabled, it can be configured, and
> > it can be left as is.
> >
> I know, that the old style can be kept by either using udev (withg persistent-
> net.rules for example) or by a kernel parm (something like "ifnet.rename=0, or
> similar, forgot the correct syntax)
>
> > > However, I discovered many packages, where are still the old names
> > > preconfigured with the old names.
> >
> > Some examples are in order.
> >
> I had to correct /etc/network/interfaces, kismet, wicd-*, powertweak, snort
> and some others. No big deal.

I don't think we've been told whether /e/n/i needed correcting after
installation, after a dist-upgrade, or some other circumstance.

> > Most of the server-side packages that I can think of are either bind to all
> > available interfaces by default, or bind to lo, which is still here.
>
> There were more the desktop users with laptops in my mind.
>
> >
> > > I know, the last one might be problematic, because the developer never can
> > > know, whhich interface is used (eth0? eth1? wlan0? whatever)
> >
> > Or, for instance, en0p2gibberish. They call them Unpredictable Device
> > Named for a reason.
>
> Yes, thsis is another thing, which I am thinking of: The names could change
> (in case, when there are more than one network devices are active or the order
> of activing changed).

Can you elaborate on these name changes. AIUI the reason they're
jokingly called Unpredictable Device Names is because anyone who's not
into hardware is not going to know the name when they buy a laptop/
add a new NIC/whatever. After that, the name stays Predictable and
Persistent regardless of activation, booting'sorder of discovery etc.

> In the past, I forced the order with persistent-
> net.rules. Dunno, if normal users can deal with it. Can it your Mom or your
> Dad? Grandpa? Grandma?
>  
> > > For myself I got the solution: just edited all configs to the new names,
> > > but I believe, for unexperienced users, this could be problematic.
> >
> > So-called "unexperienced" users should not meddle in servers'
> > configuration in the first place.
> > And NIC configuration is hardly relevant for a typical desktop.
> >
> > > And I also believe, an unexperienced user gets in trouble, when nobody
> > > points him, where to look.
> >
> > I don't know about that. I mean, you wrote here, isn't it? Nobody's
> > stopping this hypothetical "unexperienced" users to do the same.
>
> Remember, this list is in English, not all people do speak English well
> (included myself), and I doubt, most people want to spare the time, to crawl
> through all the lists. They want it just work.
> >
> > > You do not need to look for a solution for me, I just wanted to remember
> > > this thing and hope, we should keep this little problem in mind. Maybe
> > > this is worth a discussion, if not, please excuse the noise.

Cheers,
David.

12