Re: "Ethernet trouble" thread

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. > > [...]

Re: "Ethernet trouble" thread

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

Re: "Ethernet trouble" thread

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 >

Re: Ethernet trouble

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. > >

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

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.

Re: Ethernet trouble

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

Re: Ethernet trouble

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. >

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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"

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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). ---

Re: Ethernet trouble

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). > >

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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:

Re: Ethernet trouble

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

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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 :,

Re: Ethernet trouble

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

Re: Ethernet trouble

> 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

Re: Ethernet trouble

> 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.

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

> 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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

(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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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'

Re: Ethernet trouble

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

Re: Ethernet trouble

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

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,

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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

Re: Ethernet trouble

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,

Ethernet trouble

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). I've rebooted 3 times, and they don't change. My /etc/network/interfaces had config info for 6 and 7

Re: Ethernet trouble

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

Re: Ethernet trouble

-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

Ethernet trouble

Seeking help using a network card in a PC. The card is a Linksys Etherfast 10/100 LAN card. The PC is a 'home-built' machine, using an Asus P3V4X motherboard. BIOS is Award Medallion BIOS v6.0. Debian is as installed from the 2.2 official CDs, plus a custom kernel in case it helped - no

Re: Ethernet trouble

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

Re: Ethernet trouble

-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