Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #206453 > unrolled thread

Discussion? New names of betwork devices

Back to article view | Back to linux.debian.user

Contents

  Discussion? New names of betwork devices Hans <hans.ullrich@loop.de> - 2019-03-22 16:10 +0100
    Re: Discussion? New names of betwork devices Reco <recoverym4n@enotuniq.net> - 2019-03-22 17:20 +0100
      Re: Discussion? New names of betwork devices Hans <hans.ullrich@loop.de> - 2019-03-22 17:50 +0100
        Re: Discussion? New names of betwork devices Reco <recoverym4n@enotuniq.net> - 2019-03-22 18:30 +0100
        Re: Discussion? New names of betwork devices Mart van de Wege <mvdwege@gmail.com> - 2019-03-23 19:30 +0100
          Re: Discussion? New names of betwork devices Nicholas Geovanis <nickgeovanis@gmail.com> - 2019-03-23 20:40 +0100
          Re: Discussion? New names of betwork devices Nicholas Geovanis <nickgeovanis@gmail.com> - 2019-03-23 20:40 +0100
        Re: Discussion? New names of betwork devices David Wright <deblis@lionunicorn.co.uk> - 2019-03-24 18:20 +0100
      Re: Discussion? New names of betwork devices Hans <hans.ullrich@loop.de> - 2019-03-23 18:30 +0100
    Re: Discussion? New names of betwork devices Joe <joe@jretrading.com> - 2019-03-22 21:00 +0100
      Re: Discussion? New names of betwork devices ghe <ghe@slsware.net> - 2019-03-22 23:20 +0100
        Re: Discussion? New names of betwork devices Felix Miata <mrmazda@earthlink.net> - 2019-03-22 23:40 +0100
          Re: Discussion? New names of betwork devices deloptes <deloptes@gmail.com> - 2019-03-23 07:40 +0100
            Re: Discussion? New names of betwork devices Felix Miata <mrmazda@earthlink.net> - 2019-03-23 09:40 +0100
              Re: Discussion? New names of betwork devices David Wright <deblis@lionunicorn.co.uk> - 2019-03-24 04:10 +0100
                Re: Discussion? New names of betwork devices Felix Miata <mrmazda@earthlink.net> - 2019-03-24 04:30 +0100
                  Re: Discussion? New names of betwork devices deloptes <deloptes@gmail.com> - 2019-03-24 07:30 +0100
                    Re: Discussion? New names of betwork devices Felix Miata <mrmazda@earthlink.net> - 2019-03-24 08:10 +0100
                  Re: Discussion? New names of betwork devices David Wright <deblis@lionunicorn.co.uk> - 2019-03-24 18:10 +0100
        Re: Discussion? New names of betwork devices Michael Stone <mstone@debian.org> - 2019-03-24 20:30 +0100
    Re: Discussion? New names of betwork devices ghe <ghe@slsware.net> - 2019-03-22 21:00 +0100

Page 1 of 2  [1] 2  Next page →

#206453 — Discussion? New names of betwork devices

[Multipart message — attachments visible in raw view] — view raw

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 

[toc] | [next] | [standalone]

#206458

	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

[toc] | [prev] | [next] | [standalone]

#206463

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#206466

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

[toc] | [prev] | [next] | [standalone]

#206527

Hans <hans.ullrich@loop.de> 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.

[toc] | [prev] | [next] | [standalone]

#206529

[Multipart message — attachments visible in raw view] — view raw

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 <nickgeovanis@gmail.com>
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 <mvdwege@gmail.com> wrote:
>
>> Hans <hans.ullrich@loop.de> 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.
>>
>>

[toc] | [prev] | [next] | [standalone]

#206530

[Multipart message — attachments visible in raw view] — view raw

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 <mvdwege@gmail.com> wrote:

> Hans <hans.ullrich@loop.de> 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.
>
>

[toc] | [prev] | [next] | [standalone]

#206547

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.

[toc] | [prev] | [next] | [standalone]

#206525

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#206478

On Fri, 22 Mar 2019 13:53:33 -0600
ghe <ghe@slsware.net> 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

[toc] | [prev] | [next] | [standalone]

#206493

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

[toc] | [prev] | [next] | [standalone]

#206494

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/

[toc] | [prev] | [next] | [standalone]

#206511

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

[toc] | [prev] | [next] | [standalone]

#206516

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/

[toc] | [prev] | [next] | [standalone]

#206533

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.

[toc] | [prev] | [next] | [standalone]

#206534

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/

[toc] | [prev] | [next] | [standalone]

#206535

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

[toc] | [prev] | [next] | [standalone]

#206536

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/

[toc] | [prev] | [next] | [standalone]

#206546

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.

[toc] | [prev] | [next] | [standalone]

#206550

On Fri, Mar 22, 2019 at 04:14:50PM -0600, ghe wrote:
>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.

Unfortunately, the software doesn't know what was written on the outside 
of the box.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web