Re: "Ethernet trouble" thread

[David Wright]

On Tue 04 Feb 2020 at 13:20:35 (+0100), Tom H wrote:
> On Mon, Feb 3, 2020 at 2:54 PM Greg Wooledge  wrote:
> > On Sat, Feb 01, 2020 at 05:45:26PM +0100, Tom H wrote:
> >>
> >> You state that it's no longer udev that renames NICs. The following's
> >> from a sid VM using svsinit+sysvrc.
> > [...]
> >> udev is renaming "eth0".
> >>
> >> You can still use "/etc/udev/rules.d/" to rename NICs. Just like with
> >> "/etc/systemd/network/*.link", you gain simple names linked to a NIC's
> >> MAC address, but lose the predictable names' advantage that swapiing
> >> out a NIC preserves its name.
> >
> > Yes, it MIGHT still work. Or it might not. Support for it has
> > been officially removed. Whatever the 70-persistent-net.rules file
> > does on your system is unique to your system.
> >
> > https://wiki.debian.org/NewInBuster#Network_interface_name_migration
> >
> >  "The buster release notes warn that the
> >  /etc/udev/rules.d/70-persistent-net.rules method for assigning
> >  persistent network interface names is no longer supported."
> >
> > https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names
> >
> >  "If your system was upgraded from an earlier release, and still uses
> >  the old-style network interface names that were deprecated with stretch
> >  (such as eth0 or wlan0), you should be aware that the mechanism of
> >  defining their names via /etc/udev/rules.d/70-persistent-net.rules is
> >  officially not supported by udev in buster (while it may still work
> >  in some cases)."
> 
> Thanks. Even though this is the official policy/statement, I don't buy it.
> 
> The problem's that "70-persistent-net.rules" has been used to rename
> NICs within the kernel "ethX" namespace. Until udev upstream declares
> the "SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="mac_address",
> NAME="net0" syntax and mechanism deprecated/obsoleted, I'll assume
> that the Debian release notes and wiki are wrongly melding the fact
> that renaming a NIC to "ethX" is deprecated (and that it might not
> work in the future), with the fact that
> "/etc/udev/rules.d/.rule" can still be used to associate a
> NIC's MAC address with a name.

I assume that's why they wrote "while it may still work in some cases".
The trouble is that so many people seem overly attached to "eth0" as
the name of their interface, even though it's about the worst name
to choose under all the new regimes, and notwithstanding that there's
an almost infinite namespace now available.

But myunderstanding is that if you're going to use udev to change
the interface name, it's important to know that it has completed
before trying to bring up the interface. That can be tricky enough,
but is made doubly difficult when the name is the same at the end
as it was to start with. What do you wait on?

Cheers,
David.

Re: "Ethernet trouble" thread

[Tom H]

On Mon, Feb 3, 2020 at 2:54 PM Greg Wooledge  wrote:
> On Sat, Feb 01, 2020 at 05:45:26PM +0100, Tom H wrote:
>>
>> You state that it's no longer udev that renames NICs. The following's
>> from a sid VM using svsinit+sysvrc.
> [...]
>> udev is renaming "eth0".
>>
>> You can still use "/etc/udev/rules.d/" to rename NICs. Just like with
>> "/etc/systemd/network/*.link", you gain simple names linked to a NIC's
>> MAC address, but lose the predictable names' advantage that swapiing
>> out a NIC preserves its name.
>
> Yes, it MIGHT still work. Or it might not. Support for it has
> been officially removed. Whatever the 70-persistent-net.rules file
> does on your system is unique to your system.
>
> https://wiki.debian.org/NewInBuster#Network_interface_name_migration
>
>  "The buster release notes warn that the
>  /etc/udev/rules.d/70-persistent-net.rules method for assigning
>  persistent network interface names is no longer supported."
>
> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names
>
>  "If your system was upgraded from an earlier release, and still uses
>  the old-style network interface names that were deprecated with stretch
>  (such as eth0 or wlan0), you should be aware that the mechanism of
>  defining their names via /etc/udev/rules.d/70-persistent-net.rules is
>  officially not supported by udev in buster (while it may still work
>  in some cases)."

Thanks. Even though this is the official policy/statement, I don't buy it.

The problem's that "70-persistent-net.rules" has been used to rename
NICs within the kernel "ethX" namespace. Until udev upstream declares
the "SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="mac_address",
NAME="net0" syntax and mechanism deprecated/obsoleted, I'll assume
that the Debian release notes and wiki are wrongly melding the fact
that renaming a NIC to "ethX" is deprecated (and that it might not
work in the future), with the fact that
"/etc/udev/rules.d/.rule" can still be used to associate a
NIC's MAC address with a name.

Re: "Ethernet trouble" thread

[Greg Wooledge]

On Sat, Feb 01, 2020 at 05:45:26PM +0100, Tom H wrote:
> You state that it's no longer udev that renames NICs. The following's
> from a sid VM using svsinit+sysvrc.
[...]
> udev is renaming "eth0".
> 
> You can still use "/etc/udev/rules.d/" to rename NICs. Just like with
> "/etc/systemd/network/*.link", you gain simple names linked to a NIC's
> MAC address, but lose the predictable names' advantage that swapiing
> out a NIC preserves its name.

Yes, it MIGHT still work.  Or it might not.  Support for it has
been officially removed.  Whatever the 70-persistent-net.rules file
does on your system is unique to your system.

https://wiki.debian.org/NewInBuster#Network_interface_name_migration

  "The buster release notes warn that the
  /etc/udev/rules.d/70-persistent-net.rules method for assigning
  persistent network interface names is no longer supported."

https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names

  "If your system was upgraded from an earlier release, and still uses
  the old-style network interface names that were deprecated with stretch
  (such as eth0 or wlan0), you should be aware that the mechanism of
  defining their names via /etc/udev/rules.d/70-persistent-net.rules is
  officially not supported by udev in buster (while it may still work
  in some cases)."

Re: Ethernet trouble

[tomas]

On Sat, Feb 01, 2020 at 09:25:06AM +0200, Andrei POPESCU wrote:
> On Vi, 31 ian 20, 23:42:52, to...@tuxteam.de wrote:
> > 
> > Exactly. I do prefer to be prepared for those corner cases and to
> > learn to deal with them. A 99.8% system is, in this context not
> > superior to a 92% system.
> 
> 89,24% of people quoting a statistic just invented it ;)

Except I wasn't quoting any statistic, but just making it up ;-P

Cheers
-- t


signature.asc
Description: Digital signature

Re: Ethernet trouble

[Andrei POPESCU]

On Vi, 31 ian 20, 15:00:15, Bob Weber wrote:
> On 1/31/20 1:36 PM, Greg Wooledge wrote:
> > On Fri, Jan 31, 2020 at 01:31:43PM -0500, Bob Weber wrote:
> > > First I created  /etc/systemd/network/10-eth0.link using the MAC address 
> > > and
> > > the name eth0.  If the MAC changes then there are other characteristics to
> > > add to the [Match] section to uniquely define the port (see above link).
> > > 
> > > ---
> > > 
> > > root@debian-ZFS ~ # cat /etc/systemd/network/10-eth0.link
> > > [Match]
> > > MACAddress=52:54:00:ea:e3:53
> > > 
> > > [Link]
> > > Name=eth0
> > > 
> > > Second I linked the default to /dev/null.
> > > 
> > > -
> > > 
> > > link -s /dev/null /etc/systemd/network/99-Default.link
> > I'm almost 100% sure that should be all lower-case, if you expect
> > it to do anything.  The file it's overriding is 99-default.link
> > (lower-case).
> > 
> > > Parsed configuration file /usr/lib/systemd/network/99-default.link
> > > Skipping empty file: /etc/systemd/network/99-Default.link
> > It's going to use the 99-default.link file because you didn't actually
> > override it.  But since you're mapping explicitly on the MAC address of
> > the interface, it doesn't really matter.

Which proves it's not actually needed ;)
 
> Sorry I missed this.  I used the lower case in all the machines on my
> network  ... m ymind thinks in upper/lower case ... too bad systemd can't.

Not sure what you mean here... filenames on *nix are usually lowercase 
(easier to type?).
 
Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Ethernet trouble

[Andrei POPESCU]

On Vi, 31 ian 20, 23:42:52, to...@tuxteam.de wrote:
> 
> Exactly. I do prefer to be prepared for those corner cases and to
> learn to deal with them. A 99.8% system is, in this context not
> superior to a 92% system.

89,24% of people quoting a statistic just invented it ;)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Ethernet trouble

[ghe]

On 1/31/20 2:42 PM, Reco wrote:

> As a programmer, you should be familiar with it :)

Very. And misconfigs too...

-- 
Glenn English

Re: Ethernet trouble

[David Wright]

On Fri 31 Jan 2020 at 14:31:56 (-0700), ghe wrote:
> On 1/31/20 11:31 AM, Bob Weber wrote:
> 
> > I just ran a test on a VM that I installed last week so it is pretty
> > much up to date.  I ran the command "ip a" which gave me the current
> > undesirable name "enp1s0" and MAC address.
> 
> Check.
> 
> > First I created  /etc/systemd/network/10-eth0.link using the MAC address
> > and the name eth0.  
> 
> Check. (changed the MAC in your cat of the link file and changed the
> name in the interfaces file)
> 
> Rebooted and:
> 
> Jan 31 12:37:56 sbox systemd[1]: Starting Raise network interfaces...
> Jan 31 12:37:56 sbox ifup[2147]: ifup: unknown interface enp7s0
> Jan 31 12:37:56 sbox systemd[1]: networking.service: Main process
> exited, code=exited, status=1/FAILURE
> Jan 31 12:37:56 sbox systemd[1]: networking.service: Failed with result
> 'exit-code'.
> Jan 31 12:37:56 sbox systemd[1]: Failed to start Raise network interfaces.
> 
> To the best of my knowledge, there is no enp7s0 anymore. Where does:
> 
> [2.445808] e1000e :07:00.0 enp7s0: renamed from eth0
> 
> happen? (dmesg | egrep enp)
> 
> Then there's another line:
> 
> [   12.130525] e1000e :07:00.0 eth0: renamed from enp7s0
> 
> That should have put eth0 back. Current guess is that sometime between
> 2.44 and 12.13, somebody tried to bring up the network interfaces and
> failed.
> 
> So in my current config, eth0 gets changed to enp7s0, ifup is called to
> bring up enp7s0, ifup fails because enp7s0 doesn't exist in the
> interfaces file, then enp7s0 gets changed back to eth0. As a programmer,
> I'm quite used to flaws in software, but lordie...

Assuming you followed Bob Weber, do you still have a symlink, ie,
link -s /dev/null /etc/systemd/network/99-Default.link
in place? What happens if you boot without it?

> And systemd is calling ifup? Which relies on the old interfaces file,
> and systemd relies on additional interface config file(s)?
> 
> After the boot, 'ifup eth0' by hand brings up the interface and ifconfig
> shows it active and with the right name and IP. (So does ip a -- I keep
> using ifconfig because that's what's in my scripts and it's what I'm
> used to.)

I really would avoid changing the interface name back to the one
the kernel chose, or any string that the kernel *might* choose;
ie, be original.

Cheers,
David.

Re: Ethernet trouble

[tomas]

On Fri, Jan 31, 2020 at 12:19:19PM -0500, Michael Stone wrote:
> On Fri, Jan 31, 2020 at 04:32:32PM +0100, to...@tuxteam.de wrote:
> >On Fri, Jan 31, 2020 at 10:10:25AM -0500, Michael Stone wrote:
> >>because they don't need to know that. This is an issue
> >>mostly for people who know a little bit, want to tinker, and become
> >>irrationally angry when they need to learn something new.)
> >
> >This is insulting. I'll try to explain.
> 
> Also, it's not insulting, it's descriptive. I'll explain.
> 
> >Once I understood it, my reaction was "meh".
> 
> And that's fine. In that case, the interface names *are not an
> issue*. They're just something that's there. If you don't like them,
> you change them. No big deal, not an issue, just a thing that can be
> configured to personal taste.

Kept from your previous post:

  "So does dismising everything new as broken because it fixes
   things you don't care about."

And this is exactly what I perceive as highly insulting: I don't
dismiss "everything new as broken...". It's a classical anti-pattern
in this discussion: "You're just resistant to change" =~ "you have
actually no sensible argument". That seems subtle, but it is
pretty condescendent.

That's not better than...

> But some people don't just say "meh",
> they get angry. They insult the software, they insult the
> developers [...]

And I find that unacceptable too. Especially insulting people.
I'm on record for coming forward and speaking up against that,
too.

I'd hope we could just get along and respect each other.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Ethernet trouble

[tomas]

On Fri, Jan 31, 2020 at 12:05:34PM -0500, Michael Stone wrote:
> On Fri, Jan 31, 2020 at 04:32:32PM +0100, to...@tuxteam.de wrote:

[...

> >See? I do care.
> 
> In context, Greg talked about the "common case" [...]

Yes, and I do appreciate highly that the "non-common case" is
still possible.

> >Once I understood it, my reaction was "meh".
> 
> You still seem to not fully understand it. (Specifically, the
> difference between "persistent" names and "predictable" names.

Oh, I sure do.
> One
> of the problems systemd was trying to solve was predictability in
> the absence of persistent storage at boot time, e.g., for initial
> installation, or for remote storage.)

I get that. As I already mentioned, I was confronted with that kind
of problem "back then", Debian 3.1 aka Sarge. "Meh" means... "it
doesn't really solve the problem -- so it's not worth the added
complexity" -- as always, to me.

[...]

> So does dismising everything new as broken because it fixes things
> you don't care about.

Keep that for the next post...

> The bottom line is that in most cases the predictable names "just
> work". In some corner cases something goes wrong, just like in some
> corner cases every preceding system went wrong.

Exactly. I do prefer to be prepared for those corner cases and to
learn to deal with them. A 99.8% system is, in this context not
superior to a 92% system.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Ethernet trouble

[Michael Stone]

On Sat, Feb 01, 2020 at 12:28:51AM +0300, Reco wrote:

Hi.

On Fri, Jan 31, 2020 at 03:57:44PM -0500, Michael Stone wrote:

FWIW, I would never force something to use "eth0" because it makes it
impossible to see at first glance that all of the default behavior has
been overridden.


If you see a network interface called eth0 in a "modern" Debian it can
mean three things only:

1) Said default behaviour is overridden already.
2) You're using that rare ARM SOC to which x86-centric udev rules just
do not apply, and yes, that particular NIC is not USB-attached.
3) You're in a container, there's no udev here.


Actually, eth0 is the default for most VMs. But the point is that 
"predictable names turned off" would be the likely suspicion, and 
"someone forced a particular interface to be named eth0 based on its mac 
address" would be much more unexpected.



I suspect it would also break horribly if you add another NIC that
initializes before the one you're trying to rename to eth0.


... Unless you do it the right way by using NamePolicy=kernel. Why
bother with renaming eth0 to eth0 if you can avoid renaming at all?


Because that's what someone wanted to do. I'm just saying I wouldn't do 
it.

Re: Ethernet trouble

[Reco]

On Fri, Jan 31, 2020 at 02:31:56PM -0700, ghe wrote:
> So in my current config, eth0 gets changed to enp7s0, ifup is called to
> bring up enp7s0, ifup fails because enp7s0 doesn't exist in the
> interfaces file, then enp7s0 gets changed back to eth0. As a programmer,
> I'm quite used to flaws in software, but lordie...

Using any software (and udev in particular) in a wrong way will give you
wrong results. As a programmer, you should be familiar with it :)

Try this link file:

[Match]
Driver=e1000e
[Link]
MACAddressPolicy=none
NamePolicy=kernel


Long story short, NIC double renaming is wrong, and matching a NIC by
its MAC alone is wrong too.


> And systemd is calling ifup? Which relies on the old interfaces file,
> and systemd relies on additional interface config file(s)?

The software merely does what it's told to do.

Reco

Re: Ethernet trouble

[ghe]

On 1/31/20 11:31 AM, Bob Weber wrote:

> I just ran a test on a VM that I installed last week so it is pretty
> much up to date.  I ran the command "ip a" which gave me the current
> undesirable name "enp1s0" and MAC address.

Check.

> First I created  /etc/systemd/network/10-eth0.link using the MAC address
> and the name eth0.  

Check. (changed the MAC in your cat of the link file and changed the
name in the interfaces file)

Rebooted and:

Jan 31 12:37:56 sbox systemd[1]: Starting Raise network interfaces...
Jan 31 12:37:56 sbox ifup[2147]: ifup: unknown interface enp7s0
Jan 31 12:37:56 sbox systemd[1]: networking.service: Main process
exited, code=exited, status=1/FAILURE
Jan 31 12:37:56 sbox systemd[1]: networking.service: Failed with result
'exit-code'.
Jan 31 12:37:56 sbox systemd[1]: Failed to start Raise network interfaces.

To the best of my knowledge, there is no enp7s0 anymore. Where does:

[2.445808] e1000e :07:00.0 enp7s0: renamed from eth0

happen? (dmesg | egrep enp)

Then there's another line:

[   12.130525] e1000e :07:00.0 eth0: renamed from enp7s0

That should have put eth0 back. Current guess is that sometime between
2.44 and 12.13, somebody tried to bring up the network interfaces and
failed.

So in my current config, eth0 gets changed to enp7s0, ifup is called to
bring up enp7s0, ifup fails because enp7s0 doesn't exist in the
interfaces file, then enp7s0 gets changed back to eth0. As a programmer,
I'm quite used to flaws in software, but lordie...

And systemd is calling ifup? Which relies on the old interfaces file,
and systemd relies on additional interface config file(s)?

After the boot, 'ifup eth0' by hand brings up the interface and ifconfig
shows it active and with the right name and IP. (So does ip a -- I keep
using ifconfig because that's what's in my scripts and it's what I'm
used to.)

-- 
Glenn English

Re: Ethernet trouble

[Reco]

Hi.

On Fri, Jan 31, 2020 at 03:57:44PM -0500, Michael Stone wrote:
> FWIW, I would never force something to use "eth0" because it makes it
> impossible to see at first glance that all of the default behavior has
> been overridden.

If you see a network interface called eth0 in a "modern" Debian it can
mean three things only:

1) Said default behaviour is overridden already.
2) You're using that rare ARM SOC to which x86-centric udev rules just
do not apply, and yes, that particular NIC is not USB-attached.
3) You're in a container, there's no udev here.


> I suspect it would also break horribly if you add another NIC that
> initializes before the one you're trying to rename to eth0.

... Unless you do it the right way by using NamePolicy=kernel. Why
bother with renaming eth0 to eth0 if you can avoid renaming at all?

But the real fun with binding an interface name to a MAC starts once one
discovers 802.1q and tries to use it :) 

Reco

Re: Ethernet trouble

[Michael Stone]

On Fri, Jan 31, 2020 at 03:29:44PM -0500, Bob Weber wrote:

On 1/31/20 1:41 PM, Michael Stone wrote:
   You went through more effort than you needed to. You can turn off
   predictable names by simply booting with net.ifnames=0 on the kernel
   command line (you can make that permanent by editing GRUB_CMDLINE_LINUX= in
   /etc/default/grub and running update-grub).


The net.ifnames=0 used to work on my 2 port machine but quit about a year ago. 
Messed up my firewall rules.  Not very nice to have the internet side connected
to LAN port!   That's when I went through the pain of understanding the systemd
way!


Yup, there's definitely a problem that needed to be solved. But when 
people keep asking for things to go back to the way they used to be 
because the new way is overly complicated, that's how to do it quickly 
and simply.


There's also no need to disable 99-default.link if you add a new .link 
with new rules that override the defaults.


FWIW, I would never force something to use "eth0" because it makes it 
impossible to see at first glance that all of the default behavior has 
been overridden. I suspect it would also break horribly if you add 
another NIC that initializes before the one you're trying to rename to 
eth0. Instead I'd give it a name like "internal0" or somesuch, so it's 
clear that there's manual naming, and as a bonus it's a name that 
includes a description of its intended use.

Re: Ethernet trouble

[Bob Weber]

On 1/31/20 1:41 PM, Michael Stone wrote:

On Fri, Jan 31, 2020 at 01:31:43PM -0500, Bob Weber wrote:

First I created /etc/systemd/network/10-eth0.link using the MAC address and
the name eth0.  If the MAC changes then there are other characteristics to add
to the [Match] section to uniquely define the port (see above link).

---

root@debian-ZFS ~ # cat /etc/systemd/network/10-eth0.link
[Match]
MACAddress=52:54:00:ea:e3:53

[Link]
Name=eth0


You went through more effort than you needed to. You can turn off predictable 
names by simply booting with net.ifnames=0 on the kernel command line (you can 
make that permanent by editing GRUB_CMDLINE_LINUX= in /etc/default/grub and 
running update-grub).


The net.ifnames=0 used to work on my 2 port machine but quit about a year ago.  
Messed up my firewall rules.  Not very nice to have the internet side connected 
to LAN port!   That's when I went through the pain of understanding the systemd way!


--


*...Bob*

Re: Ethernet trouble

[Bob Weber]

On 1/31/20 1:36 PM, Greg Wooledge wrote:

On Fri, Jan 31, 2020 at 01:31:43PM -0500, Bob Weber wrote:

First I created  /etc/systemd/network/10-eth0.link using the MAC address and
the name eth0.  If the MAC changes then there are other characteristics to
add to the [Match] section to uniquely define the port (see above link).

---

root@debian-ZFS ~ # cat /etc/systemd/network/10-eth0.link
[Match]
MACAddress=52:54:00:ea:e3:53

[Link]
Name=eth0


Second I linked the default to /dev/null.

-

link -s /dev/null /etc/systemd/network/99-Default.link

I'm almost 100% sure that should be all lower-case, if you expect
it to do anything.  The file it's overriding is 99-default.link
(lower-case).


Parsed configuration file /usr/lib/systemd/network/99-default.link
Skipping empty file: /etc/systemd/network/99-Default.link

It's going to use the 99-default.link file because you didn't actually
override it.  But since you're mapping explicitly on the MAC address of
the interface, it doesn't really matter.

Sorry I missed this.  I used the lower case in all the machines on my network  
... m ymind thinks in upper/lower case ... too bad systemd can't.  I went back 
and renamed the file to lower case and got this output from the udevadm command.


-

SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link /sys/class/net/eth0
Trying to open "/etc/systemd/hwdb/hwdb.bin"...
Trying to open "/etc/udev/hwdb.bin"...
Trying to open "/usr/lib/systemd/hwdb/hwdb.bin"...
Trying to open "/lib/systemd/hwdb/hwdb.bin"...
Trying to open "/lib/udev/hwdb.bin"...
=== trie on-disk ===
tool version:  244
file size:    10287564 bytes
header size 80 bytes
strings    2145012 bytes
nodes  8142472 bytes
Load module index
Found container virtualization none.
timestamp of '/etc/systemd/network' changed
Skipping overridden file '/usr/lib/systemd/network/99-default.link'.
Skipping empty file: /etc/systemd/network/99-default.link
Parsed configuration file /usr/lib/systemd/network/73-usb-net-by-mac.link
Parsed configuration file /etc/systemd/network/10-eth0.link
Created link configuration context.
ID_NET_DRIVER=virtio_net
eth0: Config file /etc/systemd/network/10-eth0.link is applied
ethtool: autonegotiation is unset or enabled, the speed and duplex are not 
writable.
eth0: Device has name_assign_type=4
Using default interface naming scheme 'v243'.
eth0: Policies didn't yield a name, using specified Name=eth0.
ID_NET_LINK_FILE=/etc/systemd/network/10-eth0.link
ID_NET_NAME=eth0
Unload module index
Unloaded link configuration context.


New lines:

Skipping overridden file '/usr/lib/systemd/network/99-default.link'

Skipping empty file: /etc/systemd/network/99-default.link


That's more like it.


--


*...Bob*

Re: Ethernet trouble

[Michael Stone]

On Fri, Jan 31, 2020 at 01:31:43PM -0500, Bob Weber wrote:

First I created  /etc/systemd/network/10-eth0.link using the MAC address and
the name eth0.  If the MAC changes then there are other characteristics to add
to the [Match] section to uniquely define the port (see above link).

---

root@debian-ZFS ~ # cat /etc/systemd/network/10-eth0.link
[Match]
MACAddress=52:54:00:ea:e3:53

[Link]
Name=eth0


You went through more effort than you needed to. You can turn off 
predictable names by simply booting with net.ifnames=0 on the kernel 
command line (you can make that permanent by editing GRUB_CMDLINE_LINUX= 
in /etc/default/grub and running update-grub).

Re: Ethernet trouble

[Greg Wooledge]

On Fri, Jan 31, 2020 at 01:31:43PM -0500, Bob Weber wrote:
> First I created  /etc/systemd/network/10-eth0.link using the MAC address and
> the name eth0.  If the MAC changes then there are other characteristics to
> add to the [Match] section to uniquely define the port (see above link).
> 
> ---
> 
> root@debian-ZFS ~ # cat /etc/systemd/network/10-eth0.link
> [Match]
> MACAddress=52:54:00:ea:e3:53
> 
> [Link]
> Name=eth0
> 
> 
> Second I linked the default to /dev/null.
> 
> -
> 
> link -s /dev/null /etc/systemd/network/99-Default.link

I'm almost 100% sure that should be all lower-case, if you expect
it to do anything.  The file it's overriding is 99-default.link
(lower-case).

> Parsed configuration file /usr/lib/systemd/network/99-default.link
> Skipping empty file: /etc/systemd/network/99-Default.link

It's going to use the 99-default.link file because you didn't actually
override it.  But since you're mapping explicitly on the MAC address of
the interface, it doesn't really matter.

Re: Ethernet trouble

[Bob Weber]

On 1/31/20 2:05 AM, ghe wrote:



On Jan 30, 2020, at 04:48 PM, Bob Weber  wrote:
"Example 3. Debugging NamePolicy= assignments" near the bottom of the page at
"https://www.freedesktop.org/software/systemd/man/systemd.link.html";

Yeah. That's one I looked at. The one with the table of the Ethernet speeds and 
duplexity. And the list and descriptions of data that're sometimes needed in 
the file.

I'll look at this again tomorrow, Bob, but I'm really not impressed with the way systemd 
is setting up the Ethernet interfaces. Like I said before, "Counting Ethernet 
interfaces isn't rocket science." But it can be made so if you make things complex 
and spread the config over several dirs and several files, some of which are explained in 
the dox but turn out not to exist on my Buster disk.

Somehow, back in the eth days, the data in Debian's /etc/network/interfaces 
file was enough to get networking going. Then, on an Ethernet network, the 
Ethernet chips pretty well figured out the best speed and duplex all by 
themselves as soon as they connected to something.


This nameing configuration has worked on 5 Debian systems all running updated 
testing.

And counting interfaces has worked for me for a couple decades, on many systems 
and several OSs. But I'll find your earlier email and try systemd one more 
time. It'd be nice for the interface names to be, as systemd calls it, 
'consistent.'

And, FWIF, I appreciate your help and advice...

I just ran a test on a VM that I installed last week so it is pretty much up to 
date.  I ran the command "ip a" which gave me the current undesirable name 
"enp1s0" and MAC address.


First I created  /etc/systemd/network/10-eth0.link using the MAC address and the 
name eth0.  If the MAC changes then there are other characteristics to add to 
the [Match] section to uniquely define the port (see above link).


---

root@debian-ZFS ~ # cat /etc/systemd/network/10-eth0.link
[Match]
MACAddress=52:54:00:ea:e3:53

[Link]
Name=eth0


Second I linked the default to /dev/null.

-

link -s /dev/null /etc/systemd/network/99-Default.link


Next I ran the test command from Example 3 at the above link to see what udevadm 
thinks.


-

SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link 
/sys/class/net/enp1s0
Trying to open "/etc/systemd/hwdb/hwdb.bin"...
Trying to open "/etc/udev/hwdb.bin"...
Trying to open "/usr/lib/systemd/hwdb/hwdb.bin"...
Trying to open "/lib/systemd/hwdb/hwdb.bin"...
Trying to open "/lib/udev/hwdb.bin"...
=== trie on-disk ===
tool version:  244
file size:    10287564 bytes
header size 80 bytes
strings    2145012 bytes
nodes  8142472 bytes
Load module index
Found container virtualization none.
timestamp of '/etc/systemd/network' changed
Parsed configuration file /usr/lib/systemd/network/99-default.link
Skipping empty file: /etc/systemd/network/99-Default.link
Parsed configuration file /usr/lib/systemd/network/73-usb-net-by-mac.link
Parsed configuration file /etc/systemd/network/10-eth0.link
Created link configuration context.
ID_NET_DRIVER=virtio_net
enp1s0: Config file /etc/systemd/network/10-eth0.link is applied
ethtool: autonegotiation is unset or enabled, the speed and duplex are not 
writable.
enp1s0: Device has name_assign_type=4
Using default interface naming scheme 'v243'.
enp1s0: Policies didn't yield a name, using specified Name=eth0.
ID_NET_LINK_FILE=/etc/systemd/network/10-eth0.link
ID_NET_NAME=eth0
Unload module index
Unloaded link configuration context.


Notice the ID_NET_NAME=eth0 is what I wanted.  Also option to the udevadm 
command /sys/class/net/enp1s0 contains the current undesirable name of the 
interface (enp1s0).


Now I rebooted the VM.  I ran the "ip a" command again.

-
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000

    link/ether 52:54:00:ea:e3:53 brd ff:ff:ff:ff:ff:ff
    inet 192.168.240.228/24 brd 192.168.240.255 scope global dynamic 
noprefixroute eth0

   valid_lft 3550sec preferred_lft 3550sec
    inet6 fe80::5054:ff:feea:e353/64 scope link noprefixroute
   valid_lft forever preferred_lft forever


Just what I wanted.


Now running the udevadm command from before with the old name fails:

SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link 
/sys/class/net/enp1s0
Trying to open "/etc/systemd/hwdb/hwdb.bin"...
Trying to open "/etc/udev/hwdb.bin"...
Trying to open "/usr/lib/systemd/hwdb/hwdb.bin"...
Trying to open "/lib/systemd/hwdb/hwdb.bin"...
Trying to open "/lib/udev/hwdb.bin"...
=== trie on-disk ===
tool version:  244
file size:    10287564 bytes
header size 80 bytes
strings    2145012 bytes
nodes  8142472 bytes
Load module index
Found container virtualization none.
timestamp of '/etc/systemd/network' changed
Parsed configuration file /usr/lib/systemd/network/99-default.link
Skipping empty file: /etc/systemd/network/99-Default.link
Parsed configuration file /usr/lib/systemd/network

Re: Ethernet trouble

[Michael Stone]

On Fri, Jan 31, 2020 at 04:32:32PM +0100, to...@tuxteam.de wrote:

On Fri, Jan 31, 2020 at 10:10:25AM -0500, Michael Stone wrote:

because they don't need to know that. This is an issue
mostly for people who know a little bit, want to tinker, and become
irrationally angry when they need to learn something new.)


This is insulting. I'll try to explain.


Also, it's not insulting, it's descriptive. I'll explain.


Once I understood it, my reaction was "meh".


And that's fine. In that case, the interface names *are not an issue*. 
They're just something that's there. If you don't like them, you change 
them. No big deal, not an issue, just a thing that can be configured to 
personal taste. But some people don't just say "meh", they get angry. 
They insult the software, they insult the developers, they rant about 
how all the decisions were stupid. They may explain that there's a 
simple solution that should have been implemented if only the developers 
were smarter or not part of a *conspiracy* to make horrible software. 
Now, for no good reason, a trivial matter like an interface name has 
become "an issue". If that's not you--great!--there's no need to be 
insulted because it must not have been about you.


Even at their worst the debian lists are actually pretty good. But you 
might be surprised at the level of vitriol that developers can get over 
what are really unimportant matters in the grand scheme of things. If 
you aren't the kind to get angry about interface names you might be 
surprised that developers actually get death threats over such trivial 
nonsense. Anyway, that's how I define "an issue" vs "a configurable 
default".

Re: Ethernet trouble

[Michael Stone]

On Fri, Jan 31, 2020 at 04:32:32PM +0100, to...@tuxteam.de wrote:

On Fri, Jan 31, 2020 at 10:10:25AM -0500, Michael Stone wrote:

On Fri, Jan 31, 2020 at 10:01:23AM -0500, Greg Wooledge wrote:
>The primary drawback of this method is that in the common case of a
>single-user home desktop system with a single NIC, the name "eth0" is
>expected to Just Work for whatever NIC happens to be in the system at
>the time.

It's also fundamentally unpredictable for the same reason that you
can't just rely on the kernel name in the first place [...]



to work around. (And really, in the single user/single nic desktop
case, the user doesn't even *care* if the installer configures eth0
or foo11


See? I do care.


In context, Greg talked about the "common case". In the common case, for 
the purpose of actually designing an OS, the user doesn't care. In your 
particular case, for aesthetic reasons or whatever, you care. That's not 
the common case, that's the you case. The common case is that the 
installer configures the network and then it never gets touched again. 
The common case is that the user probably doesn't even know what the 
interface name is, or thinks it's something like "my wireless card", 
because in the common case the user shouldn't have to know.



When the persistent schema came up, I took interest in it, since
I had hit the problem quite a few times and well, if someone
solved it, I'd like to know.

Once I understood it, my reaction was "meh".


You still seem to not fully understand it. (Specifically, the difference 
between "persistent" names and "predictable" names. One of the problems 
systemd was trying to solve was predictability in the absence of 
persistent storage at boot time, e.g., for initial installation, or for 
remote storage.)



but for me and my installations, it wasn't worth the more
complicated names. I still do "sudo ifup eth0" and don't really
want to do "sudo ifup &$#*@%#". I had seen those things before
(was it Solaris) and -- oh well.


Solaris did it for reasons. Eventually linux tried to fill roles which 
required the same sort of solution for the same sort of reasons. "I 
don't want to" isn't a rational argument that anyone can address. If you 
just don't want to do it, then ok, but why share that with everyone?



Now dismissing folks who don't share your opinion on some
shiny new thing as "just resistant to change" or "tinkerers"
is a horrible antipattern. Please don't do that. It leads
to ugly discussions and hurt feelings. Been there, done that.


So does dismising everything new as broken because it fixes things you 
don't care about.


The bottom line is that in most cases the predictable names "just work". 
In some corner cases something goes wrong, just like in some corner 
cases every preceding system went wrong. For the predictable scheme the 
most likely thing to go wrong is that you've got a system whose firmware 
is broken. Unfortunately that's really hard to fix. On the bright side 
there are workarounds and alternatives for those who need them or for 
particular use cases which aren't well suited to the defaults.


If you have some unusual requirement where you want the name to be one 
specific thing and you'll be unhappy if it's anything else, well, that 
can also be achieved! But it's certainly not something that needs to 
drive the common case defaults.

Re: Ethernet trouble

[tomas]

On Fri, Jan 31, 2020 at 11:05:32AM -0500, Greg Wooledge wrote:
> On Fri, Jan 31, 2020 at 04:53:28PM +0100, to...@tuxteam.de wrote:
> > I see, thanks. I must admit that I don't know very much about how
> > systemd names network interfaces. In practice, what I get to see
> > roughly follows the known conventions (bus number, etc).
> > 
> > Udev is/was just a mechanism to implement those conventions. Or
> > different ones.
> 
> > Is it using something else than udev, these days?
> 
> Yes.
> 
> https://wiki.debian.org/NetworkInterfaceNames
> http://manpages.debian.org/systemd.link

Thanks.

Now I understand the confusion. What's being called "udev" here
was just that one MAC-based "70-persistent-rules" thingy. Nowadays
(Buster, no systemd but udev) Debian ships udev rules implementing
the "predictable" scheme (as it's called in the above wiki). Cf.
75-net-description.rules, for example.

And systemd relies on udev to actually implement its mechanism,
as can be guessed from the man page you link to above.

So -- strictly speaking, "udev" is just the mechanism, the
policy is defined by sets of udev rules (possibly disguised
as .link files whenever systemd is in control) -- and loosely
speaking, whenever folks say here "udev interface names", they
are talking about the now defunct MAC based [1] interface
names once-upon-a-time implemented by a sadly notorious
70-persistent-net.rules or something (the exact spelling
escapes me at the moment).

On my original post: I was talking about those (newer)
"predictable" interface names. I've no use for them.
Someone else might. YMMV. Etc.

Cheers

[1] This one bit me once in the ass. Remember that thing
   where a virtual machine used to roll dice on the mac
   address of its virtual interface?

-- tomás


signature.asc
Description: Digital signature

Re: Ethernet trouble

[Greg Wooledge]

On Fri, Jan 31, 2020 at 04:53:28PM +0100, to...@tuxteam.de wrote:
> I see, thanks. I must admit that I don't know very much about how
> systemd names network interfaces. In practice, what I get to see
> roughly follows the known conventions (bus number, etc).
> 
> Udev is/was just a mechanism to implement those conventions. Or
> different ones.

> Is it using something else than udev, these days?

Yes.

https://wiki.debian.org/NetworkInterfaceNames
http://manpages.debian.org/systemd.link

Re: Ethernet trouble

[tomas]

On Fri, Jan 31, 2020 at 10:38:20AM -0500, Greg Wooledge wrote:
> On Fri, Jan 31, 2020 at 04:32:32PM +0100, to...@tuxteam.de wrote:
> > When the persistent schema came up, I took interest in it, [...]
> 
> > but for me and my installations, it wasn't worth the more
> > complicated names. I still do "sudo ifup eth0" and don't really
> > want to do "sudo ifup &$#*@%#".
> 
> You are NOT talking about the udev persistent naming scheme.  You
> are talking about the systemd predictable naming scheme.
> 
> VERY different creatures.

I see, thanks. I must admit that I don't know very much about how
systemd names network interfaces. In practice, what I get to see
roughly follows the known conventions (bus number, etc).

Udev is/was just a mechanism to implement those conventions. Or
different ones.

> Under the systemd (current) scheme, you can choose whatever name
> you like for the interface.  If you want to call it "red", you can
> call it "red", and then plug a red cable in it.

Is it using something else than udev, these days?

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Ethernet trouble

[Greg Wooledge]

On Fri, Jan 31, 2020 at 04:32:32PM +0100, to...@tuxteam.de wrote:
> When the persistent schema came up, I took interest in it, [...]

> but for me and my installations, it wasn't worth the more
> complicated names. I still do "sudo ifup eth0" and don't really
> want to do "sudo ifup &$#*@%#".

You are NOT talking about the udev persistent naming scheme.  You
are talking about the systemd predictable naming scheme.

VERY different creatures.

Under the systemd (current) scheme, you can choose whatever name
you like for the interface.  If you want to call it "red", you can
call it "red", and then plug a red cable in it.

Re: Ethernet trouble

[tomas]

On Fri, Jan 31, 2020 at 10:10:25AM -0500, Michael Stone wrote:
> On Fri, Jan 31, 2020 at 10:01:23AM -0500, Greg Wooledge wrote:
> >The primary drawback of this method is that in the common case of a
> >single-user home desktop system with a single NIC, the name "eth0" is
> >expected to Just Work for whatever NIC happens to be in the system at
> >the time.
> 
> It's also fundamentally unpredictable for the same reason that you
> can't just rely on the kernel name in the first place [...]

> to work around. (And really, in the single user/single nic desktop
> case, the user doesn't even *care* if the installer configures eth0
> or foo11

See? I do care.

> because they don't need to know that. This is an issue
> mostly for people who know a little bit, want to tinker, and become
> irrationally angry when they need to learn something new.)

This is insulting. I'll try to explain.

I, for one, knew about the inherent problem with the interface
names.

When the persistent schema came up, I took interest in it, since
I had hit the problem quite a few times and well, if someone
solved it, I'd like to know.

Once I understood it, my reaction was "meh".

Sure some progress for totally naive users (which were starting
to use Linux distros more and more, which is a Good Thing), so
it made (a bit of [1]) sense to

 (a) have it as default schema and
 (b) for us, the somewhat experienced folks to understand it,
 to be able to help newbies... 

but for me and my installations, it wasn't worth the more
complicated names. I still do "sudo ifup eth0" and don't really
want to do "sudo ifup &$#*@%#". I had seen those things before
(was it Solaris) and -- oh well.

Now dismissing folks who don't share your opinion on some
shiny new thing as "just resistant to change" or "tinkerers"
is a horrible antipattern. Please don't do that. It leads
to ugly discussions and hurt feelings. Been there, done that.

Cheers

[1] afaik the jury is still out on that, but let's concede
   it, for the sake of argument.

-- tomás


signature.asc
Description: Digital signature

Re: Ethernet trouble

[Michael Stone]

On Fri, Jan 31, 2020 at 10:01:23AM -0500, Greg Wooledge wrote:

The primary drawback of this method is that in the common case of a
single-user home desktop system with a single NIC, the name "eth0" is
expected to Just Work for whatever NIC happens to be in the system at
the time.


It's also fundamentally unpredictable for the same reason that you can't 
just rely on the kernel name in the first place--even on the first 
install, if you have multiple NICs they will sometimes come up in 
a different order. For the single user/single nic desktop this isn't an 
issue, but if you're trying to on a large number of machines, and plug 
the LAN into (for example) the first on-board interface, it is a real 
PITA if sometime's that is eth0 and sometimes it's eth3 (or whatever) 
and that's a *much* harder problem to work around. (And really, in the 
single user/single nic desktop case, the user doesn't even *care* if the 
installer configures eth0 or foo11 because they don't need to know that. 
This is an issue mostly for people who know a little bit, want to 
tinker, and become irrationally angry when they need to learn something 
new.)

Re: Ethernet trouble

[tomas]

On Fri, Jan 31, 2020 at 09:52:29AM -0500, rhkra...@gmail.com wrote:
> On Friday, January 31, 2020 09:39:37 AM Dan Ritter wrote:
> > All of this would be, I think, 99% better than what we have now.
> 
> +1 -- sounds good!

Yeah, but it isn't. As Michael points out, most solutions proposed
here have been tried and none is "always good". Mac addresses, for
example, aren't as "fixed" or "stable" as one would make them out
(and actually in some case they are forcibly changed, for privacy
reasons [1]).

Whoever has been admining or near-admining for a while (I've, for
nearly as long as Unix exists) can share a bunch of stories.

Dan, RH -- believe me, you're running in circles :-)

The best one can do is to offer the necessary building blocks to
fix the problem du jour (udev does, for the moment, at least).

Persistent device names, as we know them now, are just the last
(failed) attempt. Some folks like them, some dislike them, I'm
happy & thankful that there's a way to choose with a reasonable
amount of effort.

Cheers

[1] Mobile devices and their WiFi mac address.
-- t


signature.asc
Description: Digital signature

Re: Ethernet trouble

[Greg Wooledge]

On Fri, Jan 31, 2020 at 09:39:37AM -0500, Dan Ritter wrote:
> Maybe we should ask the OS to actually help, instead of
> "helping" us.
> 
> For example, the OS knows when it is being installed. At install
> time, it could enumerate NICs and assign them permanent names
> based on the MAC addresses: eth0, eth1...
> 
> At any subsequent boot, the OS could then continue to assign the
> same names. If a device appears to be missing, the name is
> skipped. eth3 doesn't become eth2, eth2 just goes missing for
> that boot. This is immensely useful in discovering when a NIC
> has suffered hardware damage or is otherwise not present.

This is basically how the udev persistent-naming scheme worked.
Support for it was officially discontinued in buster.

The primary drawback of this method is that in the common case of a
single-user home desktop system with a single NIC, the name "eth0" is
expected to Just Work for whatever NIC happens to be in the system at
the time.

If the NIC failed and was replaced, the replacement NIC would become eth1,
rather than eth0, and this confused some people.

Prior to the udev thing, when the kernel dynamically assigned names
to interfaces in whatever order they happened to pop up during boot,
replacing a single NIC with a different single NIC would have kept
the name "eth0" the whole time.  This is what many people were expecting,
and what the udev persistent-naming scheme took away.

Now, this is all historic.  Both the pre-udev "whatever you have
gets called whatever I want to call it" scheme, and the udev
persistent-naming scheme, are unsupported.  If you choose to use
them, they may work for you, or they may not.

The currently supported approach is systemd.link(5).  If you want to
assign a name to an interface, you create a file that sets up the
mapping as you wish it to be made.  Usually from the MAC address.

This puts a slightly higher burden of knowledge on the sysadmin, but
I really don't see a better choice.  Anything that tries to magically
do the Right Thing is going to fail in at least one common scenario.
Editing a systemd.link file isn't any harder than editing the udev
persistent rules file, and if you replace a NIC and want to keep the
same name, you'll have to edit one of these files anyway.

Re: Ethernet trouble

[rhkramer]

On Friday, January 31, 2020 09:39:37 AM Dan Ritter wrote:
> All of this would be, I think, 99% better than what we have now.

+1 -- sounds good!

Re: Ethernet trouble

[Michael Stone]

On Fri, Jan 31, 2020 at 09:39:37AM -0500, Dan Ritter wrote:

Michael Stone wrote:

As a programmer you should be concerned with making sure that the packets go
in and out of the correct physical hardware. If the name doesn't relate to
the physical harder that's a harder problem to solve. You (and everyone
else) could reimplement that in software at a higher level, or accept that
this is something the OS should help with.


Maybe we should ask the OS to actually help, instead of
"helping" us.

For example, the OS knows when it is being installed. At install
time, it could enumerate NICs and assign them permanent names
based on the MAC addresses: eth0, eth1...


It's been tried, and has other problems. (As you trimmed from the 
original email.) 


When an unrecognized device is plugged in, whether during runtime or at
boot time, it gets the next sequential permanent name.


Which also has its own problems. (Is it "eth0" the old kernel version or 
"eth0" the renamed version? Don't worry, it's really easy to explain the 
difference to someone having problems on a mailing list.)



All of this would be, I think, 99% better than what we have now.


And yet, it wasn't. :) Maybe with the stuff you described that doesn't 
exist that you think should get written (by someone) it would be better, 
but we don't know since it hasn't been written. Even if it was written 
it wouldn't be reliably available for several kernel & OS releases 
because compatibility and upgrades. 

Really, if there was a simple solution that worked better than the 
existing solution for all cases, it would get used. Since it isn't, 
there may be reasons...

Re: Ethernet trouble

[Dan Ritter]

Michael Stone wrote: 
> As a programmer you should be concerned with making sure that the packets go
> in and out of the correct physical hardware. If the name doesn't relate to
> the physical harder that's a harder problem to solve. You (and everyone
> else) could reimplement that in software at a higher level, or accept that
> this is something the OS should help with.

Maybe we should ask the OS to actually help, instead of
"helping" us.

For example, the OS knows when it is being installed. At install
time, it could enumerate NICs and assign them permanent names
based on the MAC addresses: eth0, eth1...

At any subsequent boot, the OS could then continue to assign the
same names. If a device appears to be missing, the name is
skipped. eth3 doesn't become eth2, eth2 just goes missing for
that boot. This is immensely useful in discovering when a NIC
has suffered hardware damage or is otherwise not present.

When an unrecognized device is plugged in, whether during runtime or at
boot time, it gets the next sequential permanent name.

Finally, a simple lookup table of MAC to name should be exposed by the
kernel, and saved/loaded in the same way as firewall rules, so that people
who want to change interface name assignments can do so cleanly. The
one caveat is that a process which wants to change the MAC address of
the NIC will have to signal that specifically, rather than just
update the table. When the OS changes the MAC address, e.g. WiFi
MAC randomization, it just updates the table because it knows
what it is doing.

All of this would be, I think, 99% better than what we have now.

-dsr-

Re: Ethernet trouble

[David Wright]

On Thu 30 Jan 2020 at 11:58:47 (-0700), ghe wrote:
> On 1/29/20 7:06 PM, David Wright wrote:
> 
> > These boards, do their PCI addresses have the save bus number but
> > different slot/device numbers? dmesg or kern.log will give you
> > those: they look like NN:DD.F optionally preceded by :, where
> >  is the domain (typically ), NN is the bus, DD the device
> > of slot, F the function(s) provided by that card, eg
> > pci :00:0e.0: [10ec:8139] type 00 class 0x02
> 
> Well, I don't in any way consider myself a hardware guy, but in Java,
> Pascal, C, PERL, Python, FORTRAN, BashScripts, etc, '+' usually does the
> same thing every time I type it.

?

> I looked at dmesg a bit. I greped it for 'enp' and there was a funny
> joke in the first 2 lines (of the grep output):
> 
> [2.181317] e1000e :08:00.0 enp8s0: renamed from eth1
> [2.422105] e1000e :07:00.0 enp7s0: renamed from eth0

And did you happen upon the boards' addresses?

> So something took the rational Ethernet interface names and,
> intentionally I assume, broke hundreds of lines of code.
> 
> Once I was installing a computer that had a single Ethernet port
> soldered to the mobo (a Dell). I had an eth0, but I needed an eth1, so I
> put a card in the PCI bus. On reboot, I had eth0 and eth1. 0 was the
> mobo, 1 was the card. And it was eth1 no matter which slot it was in.

Yes, but the kernel's choice of eth0 and eth1 may not necessarily be
fixed. My experience with linux in the past was that, with two NICs,
there was no way of ensuring the order in which they were assigned.
With something like a firewall, you could end up with your WAN and LAN
interfaces reversed.

> Or if I put in a sound-card.
> 
> They were named by function, not by bus and slot. As a programmer, I'm
> much more interested in *what* they are, not *where* they are. I
> especially don't need some broken piece of software to rename them.

And take disks. With the proliferation of buses in modern PCs, there's
no guarantee that the machine will boot up and have the system disk
on the usual /dev/sda. My PC in the attic appear to enumerate the legacy
PATA before the SATAs. This laptop enumerates USB sticks in an order
that appears stable, but I have no idea whether it's really a race.

I have read of a case analogous to yours, where booting up a laptop
with a USB stick inserted would demote the internal disk to /dev/sdb.
(I think the internal disk was an SSD.)

> I know I can put them back to the 'inconsistent' names in Grub, and I'll
> be doing that -- and editing the shell scripts.
> 
> > AIUI it's nothing to do with the OS as these decisions are made by
> > the firmware on the mobo. Juggling cards in a mobo can even outwit
> > the BIOS so that the POST won't succeed: I've had mobos where I've
> > had to empty the box, power-up and save the settings, add one card
> > and repeat, add the next and so on, all to get a box with the cards
> > I wanted, located where I wanted them.
> 
> With all the 'puters I've dealt with, I've never seen anything like
> that. If I got one that did that, I'd have sent it back to Amazon and
> bought a Dell or a Raspberry Pi or a SuperMicro -- something with a
> competently written and tested BIOS.

Said attic PC is a Dell Optiplex.

> Besides, we've got UDEV. It allegedly looks at hardware and makes it
> make sense. To do that, it must, I suspect, ignore what the BIOS says
> and scan the bus(es) itself. If it does that, my Ethernet ports would
> have had the same labels, unless somebody renamed them. Would be the
> same too, if they'd just been left alone.

In your case, the sensible thing might be to use the MAC addresses,
assuming you don't change them. These Super Micro thingies could have
an IPMI built in, allowing you to change MACs to your heart's content.

> I'm not looking forward to systemd.emacs.

I got the impression there was an agenda polarising the debate. BTW,
you know who started all this renaming NICs business? Your friends at Dell.

Cheers,
David.

Re: Ethernet trouble

[Michael Stone]

On Thu, Jan 30, 2020 at 11:58:47AM -0700, ghe wrote:

I looked at dmesg a bit. I greped it for 'enp' and there was a funny
joke in the first 2 lines (of the grep output):

[2.181317] e1000e :08:00.0 enp8s0: renamed from eth1
[2.422105] e1000e :07:00.0 enp7s0: renamed from eth0

So something took the rational Ethernet interface names and,
intentionally I assume, broke hundreds of lines of code.


Because those "rational" ethernet names can be very unstable *in 
practice* on modern systems. (Devices are initialized in parallel, so 
when there are multiple interfaces present they may not always come up 
in the same order.)



Once I was installing a computer that had a single Ethernet port
soldered to the mobo (a Dell). I had an eth0, but I needed an eth1, so I
put a card in the PCI bus. On reboot, I had eth0 and eth1. 0 was the
mobo, 1 was the card. And it was eth1 no matter which slot it was in.


See above. This worked reliably on old kernels, especially static 
kernels (pre-modules) with ISA/PCI devices and works much less reliably 
in a world of hotplug PCI, USB, and modular configurations with parallel 
intialization. There was a series of hacks on top of the "rational 
names" which mapped the name to a MAC address. In practice that *also* 
renamed the ethernet devices, except in a less transparent fashion, and 
caused its own headaches when NICs were replaced.



They were named by function, not by bus and slot. As a programmer, I'm
much more interested in *what* they are, not *where* they are.


As a programmer you should be concerned with making sure that the 
packets go in and out of the correct physical hardware. If the name 
doesn't relate to the physical harder that's a harder problem to solve. 
You (and everyone else) could reimplement that in software at a higher 
level, or accept that this is something the OS should help with.



AIUI it's nothing to do with the OS as these decisions are made by
the firmware on the mobo. Juggling cards in a mobo can even outwit
the BIOS so that the POST won't succeed: I've had mobos where I've
had to empty the box, power-up and save the settings, add one card
and repeat, add the next and so on, all to get a box with the cards
I wanted, located where I wanted them.


With all the 'puters 


really?


I've dealt with, I've never seen anything like
that. If I got one that did that, I'd have sent it back to Amazon and
bought a Dell or a Raspberry Pi or a SuperMicro -- something with a
competently written and tested BIOS.


Again, many desktops have lousy firmware. Yours seems to be one of them. :-)


Besides, we've got UDEV. It allegedly looks at hardware and makes it
make sense. To do that, it must, I suspect, ignore what the BIOS says
and scan the bus(es) itself.


udev can't map a logical bus to a physical slot, only the firmware knows 
how to do that (and only if it's been properly configured by the 
vendor). udev can't even tell things like how many buses there are in 
the system, because the firmware may turn them on and off or create 
virtual buses and change those things between boots. As with most 
things, the systemd folks didn't just implement a solution looking for a 
problem, they tried to solve an actual problem that's a lot harder than 
people throwing rocks from the sidelines tend to understand.

Re: Ethernet trouble

[Stefan Monnier]

> And counting interfaces has worked for me for a couple decades, on many
> systems and several OSs.

FWIW, this whole mess exists for the simple reason that there isn't any
kind of "aliasing" available for network interfaces.  When stable names
were added to block devices, it didn't break anything because it was
introduced simply by adding the /dev/disk/by-*/* symlinks.

I wish stable interface names had been added via a similar mechanism
(which of course would have had to be added beforehand).


Stefan

Re: Ethernet trouble

[ghe]

> On Jan 30, 2020, at 04:48 PM, Bob Weber  wrote:

> "Example 3. Debugging NamePolicy= assignments" near the bottom of the page at
> "https://www.freedesktop.org/software/systemd/man/systemd.link.html";

Yeah. That's one I looked at. The one with the table of the Ethernet speeds and 
duplexity. And the list and descriptions of data that're sometimes needed in 
the file.

I'll look at this again tomorrow, Bob, but I'm really not impressed with the 
way systemd is setting up the Ethernet interfaces. Like I said before, 
"Counting Ethernet interfaces isn't rocket science." But it can be made so if 
you make things complex and spread the config over several dirs and several 
files, some of which are explained in the dox but turn out not to exist on my 
Buster disk. 

Somehow, back in the eth days, the data in Debian's /etc/network/interfaces 
file was enough to get networking going. Then, on an Ethernet network, the 
Ethernet chips pretty well figured out the best speed and duplex all by 
themselves as soon as they connected to something. 

> This nameing configuration has worked on 5 Debian systems all running updated 
> testing.

And counting interfaces has worked for me for a couple decades, on many systems 
and several OSs. But I'll find your earlier email and try systemd one more 
time. It'd be nice for the interface names to be, as systemd calls it, 
'consistent.'

And, FWIF, I appreciate your help and advice...

-- 
Glenn English

Re: Ethernet trouble

[Bob Weber]

On 1/30/20 6:17 PM, ghe wrote:

On 1/30/20 1:42 PM, Bob Weber wrote:


That's why I recommended you look into systemd link files.

I looked that up on the 'Net, and it seems pretty reasonable. I looked
around a bit and was told to edit

/usr/lib/systemd/network/99-default.link

(MAC addresses are back to hardware again, but easier to handle -- at
least they're the same whenever you look at them. And Debian puts config
files in /etc. Used to, anyway)

There's a line in 99-default.link about =persistent. The web
says that if I change that to 'none' I'll get the old names back.

I did, and I didn't.


Systemd has
the undesired effect of renaming interfaces.  You need to use the MAC
address to indicate which port should be eth0 , etc.

It looks like it'll take a lot more than changing a value in a config
file to have happen what I expect. I think I'll just leave things alone
for the time being. Now I know to expect systemd to break things, and
now I know to write around it. I was completely at a loss when those
numbers just changed for no apparent reason.

Counting Ethernet interfaces isn't rocket science.

Again, thanks list.

That's why I showed in theprevious email a file for eth0 and eth1 matching their 
MAC address.   The "99-default.link" file is taken out of the works by 
(symbolic) linking it to /dev/null.  This means whatever was in that file 
messing up the port names is gone.  The kernel command line option 
"net.ifnames=0" may or may not be needed ... try without at first.


After a reboot the names should be what you put in the  [Link] section of the 
files " /etc/systemd/network/10-eth0.link" and 
"/etc/systemd/network/20-eth0.link" assuming you put in the correct MAC address 
in the [Match] section.


If the names are are still not correct then there are some examples of a udevadm 
command like in the "Example 3. Debugging NamePolicy= assignments" near the 
bottom of the page at 
"https://www.freedesktop.org/software/systemd/man/systemd.link.html 
"


This nameing configuration has worked on 5 Debian systems all running updated 
testing.


Note: the /sys/class/net/hub0 mentioned in Example 3 should be replaced by the 
current port name found in /sys/class/net directory.


--


*...Bob*

Re: Ethernet trouble

[ghe]

On 1/30/20 1:42 PM, Bob Weber wrote:

> That's why I recommended you look into systemd link files. 

I looked that up on the 'Net, and it seems pretty reasonable. I looked
around a bit and was told to edit

/usr/lib/systemd/network/99-default.link

(MAC addresses are back to hardware again, but easier to handle -- at
least they're the same whenever you look at them. And Debian puts config
files in /etc. Used to, anyway)

There's a line in 99-default.link about =persistent. The web
says that if I change that to 'none' I'll get the old names back.

I did, and I didn't.

> Systemd has
> the undesired effect of renaming interfaces.  You need to use the MAC
> address to indicate which port should be eth0 , etc.  

It looks like it'll take a lot more than changing a value in a config
file to have happen what I expect. I think I'll just leave things alone
for the time being. Now I know to expect systemd to break things, and
now I know to write around it. I was completely at a loss when those
numbers just changed for no apparent reason.

Counting Ethernet interfaces isn't rocket science.

Again, thanks list.

-- 
Glenn English

Re: Ethernet trouble

[Stefan Monnier]

> For the rest of us, who didn't drink the OO kool-aid, overloading is
> just a nightmare.

Even outside of OO, most languages overload `+` to mean "integer
addition" when applied to integers and "double-precision float addition"
when applied to double-precision floats.

IOW while I agree that overloading is a nightmare, the absence of
overloading also tends to be a nightmare ;-)


Stefan "still not quite sure what `+` should do when applied to
Ethernet and even less so when applied to trouble"

Re: Ethernet trouble

[Bob Weber]

On 1/30/20 1:58 PM, ghe wrote:

On 1/29/20 7:06 PM, David Wright wrote:


These boards, do their PCI addresses have the save bus number but
different slot/device numbers? dmesg or kern.log will give you
those: they look like NN:DD.F optionally preceded by :, where
 is the domain (typically ), NN is the bus, DD the device
of slot, F the function(s) provided by that card, eg
pci :00:0e.0: [10ec:8139] type 00 class 0x02

Well, I don't in any way consider myself a hardware guy, but in Java,
Pascal, C, PERL, Python, FORTRAN, BashScripts, etc, '+' usually does the
same thing every time I type it.

I looked at dmesg a bit. I greped it for 'enp' and there was a funny
joke in the first 2 lines (of the grep output):

[2.181317] e1000e :08:00.0 enp8s0: renamed from eth1
[2.422105] e1000e :07:00.0 enp7s0: renamed from eth0

So something took the rational Ethernet interface names and,
intentionally I assume, broke hundreds of lines of code.

That's why I recommended you look into systemd link files. Systemd has the 
undesired effect of renaming interfaces.  You need to use the MAC address to 
indicate which port should be eth0 , etc.  See my previous post.



...Bob

Re: Ethernet trouble

[Greg Wooledge]

On Thu, Jan 30, 2020 at 11:58:47AM -0700, ghe wrote:
> Well, I don't in any way consider myself a hardware guy, but in Java,
> Pascal, C, PERL, Python, FORTRAN, BashScripts, etc, '+' usually does the
> same thing every time I type it.

In bash, += can be used to append to a string variable, to increment a
pseudo-integer variable, or to append new elements to an array.

If you restrict yourself to a raw + sign, it can be a simple string
constant that you're printing, or it can be part of an integer
addition expression, or it can be the special sentinel of a find -exec
command which terminates the -exec and requests xargs(1)-like behavior
(aggregation of many arguments into a single call).

The use of the same syntactic element with different meanings depending
on context is called "overloading".  In some programming languages,
like C++, this is considered a "feature".  You mentioned Java, which
probably does a bit of it as well.  I don't really know Java, thank gods.

For the rest of us, who didn't drink the OO kool-aid, overloading is
just a nightmare.

What this has to do with hardware, I have no idea.

Re: Ethernet trouble

[ghe]

On 1/29/20 7:06 PM, David Wright wrote:

> These boards, do their PCI addresses have the save bus number but
> different slot/device numbers? dmesg or kern.log will give you
> those: they look like NN:DD.F optionally preceded by :, where
>  is the domain (typically ), NN is the bus, DD the device
> of slot, F the function(s) provided by that card, eg
> pci :00:0e.0: [10ec:8139] type 00 class 0x02

Well, I don't in any way consider myself a hardware guy, but in Java,
Pascal, C, PERL, Python, FORTRAN, BashScripts, etc, '+' usually does the
same thing every time I type it.

I looked at dmesg a bit. I greped it for 'enp' and there was a funny
joke in the first 2 lines (of the grep output):

[2.181317] e1000e :08:00.0 enp8s0: renamed from eth1
[2.422105] e1000e :07:00.0 enp7s0: renamed from eth0

So something took the rational Ethernet interface names and,
intentionally I assume, broke hundreds of lines of code.

Once I was installing a computer that had a single Ethernet port
soldered to the mobo (a Dell). I had an eth0, but I needed an eth1, so I
put a card in the PCI bus. On reboot, I had eth0 and eth1. 0 was the
mobo, 1 was the card. And it was eth1 no matter which slot it was in.

Or if I put in a sound-card.

They were named by function, not by bus and slot. As a programmer, I'm
much more interested in *what* they are, not *where* they are. I
especially don't need some broken piece of software to rename them.

I know I can put them back to the 'inconsistent' names in Grub, and I'll
be doing that -- and editing the shell scripts.

> AIUI it's nothing to do with the OS as these decisions are made by
> the firmware on the mobo. Juggling cards in a mobo can even outwit
> the BIOS so that the POST won't succeed: I've had mobos where I've
> had to empty the box, power-up and save the settings, add one card
> and repeat, add the next and so on, all to get a box with the cards
> I wanted, located where I wanted them.

With all the 'puters I've dealt with, I've never seen anything like
that. If I got one that did that, I'd have sent it back to Amazon and
bought a Dell or a Raspberry Pi or a SuperMicro -- something with a
competently written and tested BIOS.

Besides, we've got UDEV. It allegedly looks at hardware and makes it
make sense. To do that, it must, I suspect, ignore what the BIOS says
and scan the bus(es) itself. If it does that, my Ethernet ports would
have had the same labels, unless somebody renamed them. Would be the
same too, if they'd just been left alone.

I'm not looking forward to systemd.emacs.

-- 
Glenn English

Re: Ethernet trouble

[Andrei POPESCU]

On Mi, 29 ian 20, 12:33:32, Bob Weber wrote:
>  
> I have struggled with this for hours before.  The systemd naming convention
> is explained at:
> 
> https://www.freedesktop.org/software/systemd/man/systemd.link.html
> 
> 
> Pay attention to the Examples near the bottom of the page.  There are
> udevadm commands that you can help you check the configuration.   I ended up
> with the four following configurations:
> 
> 
> 1.  kernel command line option in grub add "net.ifnames=0"
> 
> 
> 2.  /etc/systemd/network/10-eth0.link:
> 
> [Match]
> MACAddress=00:xx:xx:xx:33:ce
> 
> [Link]
> Name=eth0
> 
> 
> 3.  /etc/systemd/network/10-eth0.link:
> 
> [Match]
> MACAddress=00:xx:xx:xx:33:d2
> 
> [Link]
> Name=eth1
> 
> 
> 4.  And finally:
> 
> /etc/systemd/network/99-default.link  linked to /dev/null
> 
> 
> 
> This is my main router machine so these names have to be the same on every
> boot so the firewall rules work as desired.  There also seems to be bugs in
> systemd (I use testing) so that these appear to not work.  I think the key
> was setting 99-default.link to /dev/null.

As an additional suggestion, if one takes the time to set up per 
interface .link files one might as well use intuitive names, like 
"internet", "lan", etc.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Ethernet trouble

[David Wright]

On Wed 29 Jan 2020 at 16:52:19 (-0700), ghe wrote:
> 
> (Blush, blush)
> 
> I took those boards out, and the names went back to what I'd expected
> them to be.
> 
> I have no idea why. It doesn't make sense to me -- absolutely nothing
> changed that had anything to do with Ethernet interfaces. The OS and the
> BIOS didn't change either.
> 
> I put them back in, and the names changed.

These boards, do their PCI addresses have the save bus number but
different slot/device numbers? dmesg or kern.log will give you
those: they look like NN:DD.F optionally preceded by :, where
 is the domain (typically ), NN is the bus, DD the device
of slot, F the function(s) provided by that card, eg
pci :00:0e.0: [10ec:8139] type 00 class 0x02

If so, and if they're the only devices on that bus, then it seems
likely that when the bus is unpopulated, it doesn't get enumerated,
whereas when you insert a card, the bus has to be enumerated, and its
enumeration number is ≤ 6, pushing those ethernet buses up by one.

> When I originally installed the boards, the names didn't change.
> (Buster, IIRC, was Testing back then.)
> 
> I've written a lot of software, but my worst bugs never did anything
> like this. And I've been on Debian OSs for a long time, and I don't
> remember anything like this. That's what Sid and Testing are for, but
> Stable's for Internet servers and banks.

AIUI it's nothing to do with the OS as these decisions are made by
the firmware on the mobo. Juggling cards in a mobo can even outwit
the BIOS so that the POST won't succeed: I've had mobos where I've
had to empty the box, power-up and save the settings, add one card
and repeat, add the next and so on, all to get a box with the cards
I wanted, located where I wanted them.

People who set up servers and banks either know this stuff or get
their kit ready-built by the supplier.

Cheers,
David.

Re: Ethernet trouble

[ghe]

(Blush, blush)

I took those boards out, and the names went back to what I'd expected
them to be.

I have no idea why. It doesn't make sense to me -- absolutely nothing
changed that had anything to do with Ethernet interfaces. The OS and the
BIOS didn't change either.

I put them back in, and the names changed.

When I originally installed the boards, the names didn't change.
(Buster, IIRC, was Testing back then.)

I've written a lot of software, but my worst bugs never did anything
like this. And I've been on Debian OSs for a long time, and I don't
remember anything like this. That's what Sid and Testing are for, but
Stable's for Internet servers and banks.

I'm really sorry for bothering the list, but you did manage to point me
to the solution. Thanks.

I hear the scriptKiddies haven't fixed the FreeBSD kernel yet.

-- 
Glenn English

Re: Ethernet trouble

[Michael Stone]

On Wed, Jan 29, 2020 at 03:18:13PM -0700, ghe wrote:

But that had nothing to do with naming Ethernet interfaces. At least to
a human it didn't. They're still on the same PCI bus (0, and soldered to
the same places on MB, as I find I've said before).


some motherboards are better than others about enumerating things. the 
predictable interfaces names work great on server-class gear, but can 
get pretty wonky on consumer hardware. (the firmware is supposed to 
report the mapping between the logical pci bus to a physical slot.) if 
the reporting isn't reliable for whatever reason, you're probably a good 
candidate for changing the naming scheme. mac-based is probably the most 
reliable, but long, and you might be able to get away with the 
traditional linux ethX scheme...but if something is messing up 
initialization order that might also be unreliable.


https://major.io/2015/08/21/understanding-systemds-predictable-network-device-names/ 
has a nice discussion of where the names come from. If you run 
  udevadm info -e | less
and search for net you can see various different naming conventions for 
each device. if you're really curious you can save a copy of the udevadm 
output and if the names change again you can see why.

Re: Ethernet trouble

[Greg Wooledge]

On Wed, Jan 29, 2020 at 03:18:13PM -0700, ghe wrote:
> Do you know something interesting about screwdrivers and UDEV?

You made this mistake earlier, and now once again.  It's not udev.

You *USED* to be able to use udev to work around this.  Not any more.

The new workaround is systemd.link(5).

Re: Ethernet trouble

[ghe]

On 1/29/20 8:14 AM, Curt wrote:

> You haven't been using a screwdriver lately by any chance?

Yes. I put a couple PCI cards back in. But the E'net ports had the same
names when they were in there earlier and when they were out. The change
happened when the were put back.

But that had nothing to do with naming Ethernet interfaces. At least to
a human it didn't. They're still on the same PCI bus (0, and soldered to
the same places on MB, as I find I've said before).

I'll take the UBS3 card and the RME sound-card back out and see what
happens.

Do you know something interesting about screwdrivers and UDEV?

-- 
Glenn English

Re: Ethernet trouble

[Curt]

On 2020-01-29, ghe  wrote:
> On 1/29/20 8:04 AM, Curt wrote:
>
>> 'p' indicates the PCI bus and 's' indicates the slot, was my
>> understanding of the naming scheme. 
>
> Yeah. That's what I was told too.
>
>> Would a BIOS/Firmware upgrade
>> modify the PCI bus and slot number of your Ethernet ports?
>
> I doubt it. SuperMicro's BIOS writers aren't that stupid. I certainly
> hope they aren't.
>
> Besides:
> 1) There was no change to the BIOS.
> 2) The interfaces weren't moved anywhere. They're still soldered to the MB.
>

I see. Has there been *any* hardware change before the glitch?

https://utcc.utoronto.ca/~cks/space/blog/linux/PCINamesNotStable

 
 The resulting reality is that your PCI based names are only stable if you
 change no hardware in the system. The moment you change any hardware all bets
 are off for all hardware. You may get lucky and have some devices keep their
 current PCI names but you may well not. And I don't think you're necessarily
 protected against perverse things like two equivalent devices swapping names
 (or at least one of them winding up with what was the other's old name).

I was unaware of these corner cases that live in rather large corners,
actually.

-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: Ethernet trouble

[Bob Weber]

On 1/29/20 12:05 PM, ghe wrote:

On 1/29/20 8:04 AM, Curt wrote:


'p' indicates the PCI bus and 's' indicates the slot, was my
understanding of the naming scheme.

Yeah. That's what I was told too.


Would a BIOS/Firmware upgrade
modify the PCI bus and slot number of your Ethernet ports?

I doubt it. SuperMicro's BIOS writers aren't that stupid. I certainly
hope they aren't.

Besides:
1) There was no change to the BIOS.
2) The interfaces weren't moved anywhere. They're still soldered to the MB.

I have struggled with this for hours before.  The systemd naming convention is 
explained at:


https://www.freedesktop.org/software/systemd/man/systemd.link.html 



Pay attention to the Examples near the bottom of the page.  There are udevadm 
commands that you can help you check the configuration.   I ended up with the 
four following configurations:



1.  kernel command line option in grub add "net.ifnames=0"


2.  /etc/systemd/network/10-eth0.link:

[Match]
MACAddress=00:xx:xx:xx:33:ce

[Link]
Name=eth0


3.  /etc/systemd/network/10-eth0.link:

[Match]
MACAddress=00:xx:xx:xx:33:d2

[Link]
Name=eth1


4.  And finally:

/etc/systemd/network/99-default.link  linked to /dev/null



This is my main router machine so these names have to be the same on every boot 
so the firewall rules work as desired.  There also seems to be bugs in systemd 
(I use testing) so that these appear to not work.  I think the key was setting 
99-default.link to /dev/null.


Hope this helps.
--


*...Bob*

Re: Ethernet trouble

[ghe]

On 1/29/20 8:04 AM, Curt wrote:

> 'p' indicates the PCI bus and 's' indicates the slot, was my
> understanding of the naming scheme. 

Yeah. That's what I was told too.

> Would a BIOS/Firmware upgrade
> modify the PCI bus and slot number of your Ethernet ports?

I doubt it. SuperMicro's BIOS writers aren't that stupid. I certainly
hope they aren't.

Besides:
1) There was no change to the BIOS.
2) The interfaces weren't moved anywhere. They're still soldered to the MB.

-- 
Glenn English

Re: Ethernet trouble

[ghe]

On 1/29/20 7:15 AM, Greg Wooledge wrote:

> If you can confirm that it was caused by (or at least, occurred after)
> a firmware upgrade, then at least you'll know that you need to be ready
> for another possible change the next time you upgrade firmware.

Nope. No change(s) in the firmware.

> The enp7s0 style naming is the new "Predictable Network Interface Names"
> scheme.  That is its official name.  It is not, however, an accurate
> description of how it works in reality.  As you've seen, the names
> are NOT predictable.

No, they certainly aren't. The scheme doesn't work. The interfaces are
soldered to the MB, and there were no new ones added, so there should be
no changes in the naming.

> The new workaround to replace udev involves setting up a "dot link"
> file for each interface.  You can do lots of different things, but the
> one that most people will actually care about is mapping a MAC address
> to a name of your choice.  E.g. you can decide to map MAC address
> 01:23:45:67:89:ab to interface name "dmz0", or whatever makes sense
> for your networks.

I've fought with UDEV before, several Debian releases ago. I didn't know
UDEV was responsible for all this. Thanks for the pointer -- I'll see
what I can find in UDEVs config.

-- 
Glenn English

Re: Ethernet trouble

[Curt]

On 2020-01-29, Greg Wooledge  wrote:
> On Wed, Jan 29, 2020 at 03:04:57PM -, Curt wrote:
>> On 2020-01-29, Greg Wooledge  wrote:
>> > Did you perform a BIOS/Firmware upgrade on your motherboard?  That's
>> > one of the things that can cause this.
>> 
>> 'p' indicates the PCI bus and 's' indicates the slot, was my
>> understanding of the naming scheme. Would a BIOS/Firmware upgrade
>> modify the PCI bus and slot number of your Ethernet ports?
>
> Yes.  Yes, it can.
>

Well, then, I guess it's either that or the Screwdriver Hypothesis.


-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: Ethernet trouble

[Greg Wooledge]

On Wed, Jan 29, 2020 at 03:04:57PM -, Curt wrote:
> On 2020-01-29, Greg Wooledge  wrote:
> > Did you perform a BIOS/Firmware upgrade on your motherboard?  That's
> > one of the things that can cause this.
> 
> 'p' indicates the PCI bus and 's' indicates the slot, was my
> understanding of the naming scheme. Would a BIOS/Firmware upgrade
> modify the PCI bus and slot number of your Ethernet ports?

Yes.  Yes, it can.

Re: Ethernet trouble

[Curt]

On 2020-01-28, ghe  wrote:
> Buster, SuperMicro box
>
> The labels for my Ethernet ports have changed.

You haven't been using a screwdriver lately by any chance?

-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: Ethernet trouble

[Curt]

On 2020-01-29, Greg Wooledge  wrote:
> On Tue, Jan 28, 2020 at 04:34:15PM -0700, ghe wrote:
>> Buster, SuperMicro box
>> 
>> The labels for my Ethernet ports have changed.
>> 
>> There are 2 ports on this box. They used to be called enp6s0 and enp7s0.
>> Now they're called enp7s0 and enp8s0 (6, 7, and 8).
>
> Did you perform a BIOS/Firmware upgrade on your motherboard?  That's
> one of the things that can cause this.
>

'p' indicates the PCI bus and 's' indicates the slot, was my
understanding of the naming scheme. Would a BIOS/Firmware upgrade
modify the PCI bus and slot number of your Ethernet ports?


-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: Ethernet trouble

[tomas]

On Wed, Jan 29, 2020 at 09:15:31AM -0500, Greg Wooledge wrote:

[...]

> The enp7s0 style naming is the new "Predictable Network Interface Names"
> scheme.  That is its official name.  It is not, however, an accurate
> description of how it works in reality.  As you've seen, the names
> are NOT predictable.

Yeah. Alas. It didn't work out as expected :-/

> Prior to buster, the "Predictable" scheme was optional [...]

> In buster, however, udev's 70-persistent-net.rules is no longer supported.
> It *might* work, or it might not.

I have, in buster,

  GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0"

in /etc/default/grub. My interfaces are still eth0 and wlan0. As far
as I know it's some udev &$%*@#ggery renaming the interfaces -- the
kernel itself chooses the (also unpredictable, mind you) old style
names first.

Whatever.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Ethernet trouble

[Greg Wooledge]

On Tue, Jan 28, 2020 at 04:34:15PM -0700, ghe wrote:
> Buster, SuperMicro box
> 
> The labels for my Ethernet ports have changed.
> 
> There are 2 ports on this box. They used to be called enp6s0 and enp7s0.
> Now they're called enp7s0 and enp8s0 (6, 7, and 8).

Did you perform a BIOS/Firmware upgrade on your motherboard?  That's
one of the things that can cause this.

> Everything seems to work as 7 and 8. But this morning, it was 6 and 7.
> My shell scripts are all broken now and I'm afraid that next week, after
> I change all my scripts, something will change things back. Or increment
> them again.

If you can confirm that it was caused by (or at least, occurred after)
a firmware upgrade, then at least you'll know that you need to be ready
for another possible change the next time you upgrade firmware.

The enp7s0 style naming is the new "Predictable Network Interface Names"
scheme.  That is its official name.  It is not, however, an accurate
description of how it works in reality.  As you've seen, the names
are NOT predictable.

Prior to buster, the "Predictable" scheme was optional.  You were allowed
to opt out of it by using the /etc/udev/rules.d/70-persistent-net.rules
configuration file.  If you had one of these from an earlier release,
and upgraded to stretch, it would continue to work, and you wouldn't
even notice any changes.

In buster, however, udev's 70-persistent-net.rules is no longer supported.
It *might* work, or it might not.

The new workaround to replace udev involves setting up a "dot link"
file for each interface.  You can do lots of different things, but the
one that most people will actually care about is mapping a MAC address
to a name of your choice.  E.g. you can decide to map MAC address
01:23:45:67:89:ab to interface name "dmz0", or whatever makes sense
for your networks.

Please see:

https://wiki.debian.org/NetworkInterfaceNames#CUSTOM_SCHEMES_USING_.LINK_FILES
https://wiki.debian.org/NewInBuster#Network_interface_name_migration
https://manpages.debian.org/man/5/systemd.link

Re: Ethernet trouble

[Klaus Singvogel]

elvis wrote:
> It sounds like it is already using the consistent interface names.

It's even possible to name the devices after their MAC addresses.
Then it might be possible to identify them uniqly, on the other hand,
he will get long device names (enx78e7d1ea46da).

Didn't use this method by myself ever, no experience, so I'm pointing him
to this solution only.

Another way of naming is the troditional way: eth0.

Best regards,
Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

Re: Ethernet trouble

[elvis]

On 29/1/20 5:48 pm, Klaus Singvogel wrote:

ghe wrote:

Anybody have an explanation? Or somewhere I can start looking? Or know
how whatever labels Ethernet ports does it (or why they weren't called 0
and 1 in the first place)?

The keywords you want to search for:
udev, "consistent network device names", and debian



It sounds like it is already using the consistent interface names.




Best regards,
Klaus.


--
SURREAL now loaded. Continue? (F)ish (E)lbow (A)rtechoke F(R)apple

Re: Ethernet trouble

[Alex Mestiashvili]

My shell scripts are all broken now and I'm afraid that next week, after
I change all my scripts, something will change things back. Or increment
them again.

Anybody have an explanation? Or somewhere I can start looking? Or know
how whatever labels Ethernet ports does it (or why they weren't called 0
and 1 in the first place)?



This something is called udev.
Look in udev rules, try to unload and load kernel module for the network 
card and see what are udev actions.

Re: Ethernet trouble

[Klaus Singvogel]

ghe wrote:
> Anybody have an explanation? Or somewhere I can start looking? Or know
> how whatever labels Ethernet ports does it (or why they weren't called 0
> and 1 in the first place)?

The keywords you want to search for:
udev, "consistent network device names", and debian

Best regards,
Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

Re: Ethernet trouble

[Nick Willson]

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> A long time ago, in a galaxy far, far way, someone said...
> 
> > 
> > Seeking help using a network card in a PC.  The card is a Linksys Etherfast 
> > 10/100 LAN card.
> 
> Do you know what revision (ie v1 vs v2 vs v3 vs v4) of card this is?
> 
> [...]

It had "4.1" printed on the chip (I don't have access to the machine any 
more).  My own PC has the same model of card, working fine, and the cardboard 
box it came in has "V2.0" printed on it.  It seems like a card version upgrade 
can break the driver?

[snip]

> 
> The entire problem is that the card is not supported by the tulip driver
> 2.2.x kernel series :( It is, however, directly supported by the
> 2.4.0-testx/2.4.x series of kernels.
> 
> It's a long story as to why the driver is so far out of date.
> 
> You can get an updated driver from
> http://www.scyld.com/network/tulip.html.  I've never been able to get
> these drivers (off the scyld web pages) to work for me, but it's been a
> while since I've tried.
> 

Thanks, I got some code from there and gave it a try but failed to get the 
modules to load.  The pci-scan would load OK, but tulip produced a bunch of 
unresolved symbols.  It looked like tweaking kernel parameters could have 
helped, but I ran out of time.

I'm wondering, is anyone running a recently-bought card of this model 
(LNE100TX) in Potato?

> - -- 
> - --
> Phil Brutsche [EMAIL PROTECTED]
> 
> "There are two things that are infinite; Human stupidity and the
> universe. And I'm not sure about the universe." - Albert Einstien
> -BEGIN PGP SIGNATURE-

Thanks

-- 
Nick

Re: Ethernet trouble

[Nick Willson]

> On Sun, Sep 10, 2000 at 03:50:20AM -0700, Nick Willson wrote: 
> 
> > Here is result of "modprobe tulip":
> > /lib/modules/2.2.17/net/tulip.o: init_module: Device or resource busy
> > Hint: this error can be caused by incorrect module parameters, including 
> > invalid IO or IRQ parameters
> > /lib/modules/2.2.17/net/tulip.o: insmod /lib/modules/2.2.17/net/tulip.o 
> > failed
> > /lib/modules/2.2.17/net/tulip.o: insmod tulip failed
> 
> Are you sure your card works with the tulip-module?
> If yes, try the "old_tulip" module instead of "tulip" during
> kernel-configuration.
> 

I seem to have V2.0 of the same model of card in my own PC, working happily 
with tulip and a 2.2.17 kernel.  The problem was with a 4.1 card.  I tried 
old_tulip also, but got the same result I think (don't have access to the 
machine now).
 
> > hda: QUANTUM FIREBALLP LM20.5, 19595MB w/1900kB Cache, CHS=2498/255/63
> > hdc: ATAPI 48X CD-ROM drive, 128kB Cache
> 
> Looks like you have not activated UDMA. Have a look at #man hdparm
>

Thanks
 
> Phil
> 
> 
> -- 
> Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
> 

-- 
Nick

Re: Ethernet trouble

[Phil Brutsche]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A long time ago, in a galaxy far, far way, someone said...

> 
> Seeking help using a network card in a PC.  The card is a Linksys Etherfast 
> 10/100 LAN card.

Do you know what revision (ie v1 vs v2 vs v3 vs v4) of card this is?

[...]

> Here is result of "modprobe tulip":
> /lib/modules/2.2.17/net/tulip.o: init_module: Device or resource busy
> Hint: this error can be caused by incorrect module parameters, including 
> invalid IO or IRQ parameters
> /lib/modules/2.2.17/net/tulip.o: insmod /lib/modules/2.2.17/net/tulip.o failed
> /lib/modules/2.2.17/net/tulip.o: insmod tulip failed
> 
> Here is result of "lspci":
> 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4)
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
> 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Apollo PRO] (rev 23)
> 00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
> 00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 11)
> 00:04.3 Host bridge: VIA Technologies, Inc.: Unknown device 3050 (rev 30)
> 00:0b.0 Ethernet controller: Bridgecom, Inc: Unknown device 0985 (rev 11)
> 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 1X/2X 
> (rev 5c)

[...]

>   Bus  0, device  11, function  0:
> Ethernet controller: Unknown vendor Unknown device (rev 17).
>   Vendor id=1317. Device id=985.
  ^^^
>   Medium devsel.  Fast back-to-back capable.  IRQ 10.  Master Capable.  
> Latency=32.  Min Gnt=255.Max Lat=255.
>   I/O at 0xb000 [0xb001].
>   Non-prefetchable 32 bit memory at 0xe100 [0xe100].

The entire problem is that the card is not supported by the tulip driver
2.2.x kernel series :( It is, however, directly supported by the
2.4.0-testx/2.4.x series of kernels.

It's a long story as to why the driver is so far out of date.

You can get an updated driver from
http://www.scyld.com/network/tulip.html.  I've never been able to get
these drivers (off the scyld web pages) to work for me, but it's been a
while since I've tried.

- -- 
- --
Phil Brutsche   [EMAIL PROTECTED]

"There are two things that are infinite; Human stupidity and the
universe. And I'm not sure about the universe." - Albert Einstien
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Made with pgp4pine

iD8DBQE5u61q/ZTSZFDeHPwRAi3mAJ425GDBOVhsXw25U7OtiCiH75hqIwCgkfvj
qlI87NmZ/SKQOkWjS8o2SYY=
=cFOr
-END PGP SIGNATURE-

Re: Ethernet trouble

[Philipp Schulte]

On Sun, Sep 10, 2000 at 03:50:20AM -0700, Nick Willson wrote: 

> Here is result of "modprobe tulip":
> /lib/modules/2.2.17/net/tulip.o: init_module: Device or resource busy
> Hint: this error can be caused by incorrect module parameters, including 
> invalid IO or IRQ parameters
> /lib/modules/2.2.17/net/tulip.o: insmod /lib/modules/2.2.17/net/tulip.o failed
> /lib/modules/2.2.17/net/tulip.o: insmod tulip failed

Are you sure your card works with the tulip-module?
If yes, try the "old_tulip" module instead of "tulip" during
kernel-configuration.

> hda: QUANTUM FIREBALLP LM20.5, 19595MB w/1900kB Cache, CHS=2498/255/63
> hdc: ATAPI 48X CD-ROM drive, 128kB Cache

Looks like you have not activated UDMA. Have a look at #man hdparm

Phil