Re: Ethernet not working on a Dell notebook

On 16/03/2024 16:18, fran...@libero.it wrote: root@debian:/home/frantal# networkctl WARNING: systemd-networkd is not running, output will be incomplete. OK, so all devices are under control of NetworkManager and there is no modification of its global configuration. root@debian:/home/franta

Re: Ethernet not working on a Dell notebook

> advantage. Plugged in cable is detected immediately. With dhclient running > by ifupdown, it may take some minutes till next DHCP request is sent. [ It can take *many* minutes. ] You can use `ifplugd` to make it react to plugging/unplugging the cable, in case you don't want to use NetworkManage

Re: Ethernet not working on a Dell notebook

On 15/03/24 at 03:53, Max Nikulin wrote: On 13/03/2024 23:53, Franco Martelli wrote: On 13/03/24 at 16:06, Max Nikulin wrote: On 13/03/2024 21:52, Franco Martelli wrote: They can coexist. NetworkManager in default configuration ignores interfaces under control of ifupdown (/etc/network/interf

Re: Ethernet not working on a Dell notebook

On 13/03/2024 23:53, Franco Martelli wrote: On 13/03/24 at 16:06, Max Nikulin wrote: On 13/03/2024 21:52, Franco Martelli wrote: They can coexist. NetworkManager in default configuration ignores interfaces under control of ifupdown (/etc/network/interfaces). Detailed messages from NetworkMan

Re: Ethernet not working on a Dell notebook

Am 14.03.2024 um 17:13:12 Uhr schrieb fran...@libero.it: > After rebooting the problem remains. What does dmesg say? -- Gruß Marco Send spam to 1710432792mu...@cartoonies.org

Re: Ethernet not working on a Dell notebook

On 14/03/24 at 17:03, fran...@libero.it wrote: Hello, I did as indicated, but the connection needs the command sudo mii-tool enp19s0 -F 10baseT-FD to enable. revert the change to /etc/default/grub remove -iommu=soft amd_iommu- strings: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" run again: ~#

Fwd: Re: Ethernet not working on a Dell notebook

8 CET > Oggetto: Re: Ethernet not working on a Dell notebook > > > Am 14.03.2024 schrieb fran...@libero.it: > > > auto eth0 > > remove that.

Re: Ethernet not working on a Dell notebook

On 14/03/24 at 09:07, fran...@libero.it wrote: Hi, good morning. This is the command: /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" iommu=soft amd_iommu GRUB_CMDLINE_LINUX=""> Nope the line: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" iommu=soft amd_iommu

Re: Ethernet not working on a Dell notebook

Am 14.03.2024 schrieb fran...@libero.it: > auto eth0 remove that.

Re: Ethernet not working on a Dell notebook

root@debian:/home/frantal# dmesg |grep r8169 root@debian:/home/frantal# sudo dmesg |grep r8169 root@debian:/home/frantal# cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /e

Re: Ethernet not working on a Dell notebook

Here again the answer of journalctl: p19s0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed') mar 14 09:02:25 debian NetworkManager[565]: [1710403345.7907] dhcp4 (enp19s0): activation: beginning transaction (timeout in 45 seconds) mar 14 09:02:25 debian NetworkManag

Re: Ethernet not working on a Dell notebook

How is /etc/network/interfaces now configured? Unconfigure your interface there and only use the NetworkManager. Then it should log about autoneg. What does dmesg |grep r8169 print?

Re: Ethernet not working on a Dell notebook

Am 13.03.2024 um 17:53:40 Uhr schrieb Franco Martelli: > Sadly the useful information of the command output is truncated, > could you post it again maximizing the window before you copy? For > the journalctl command use this synta Call journalctl with --no-pager and the full line will be shown an

Re: Ethernet not working on a Dell notebook

On 13/03/24 at 18:20, fran...@libero.it wrote: Hello, I did I tried to modify as suggested.I couldn't use sudo update-grub So I gave this command: I think there is an error in the procedure Waiting for suggestions... What is the output of: ~# cat /etc/default/grub | head -10 -- Franco M

Re: Ethernet not working on a Dell notebook

Hello, I did I tried to modify as suggested.I couldn't use sudo update-grub So I gave this command: I think there is an error in the procedure Waiting for suggestions... Francesco > Il 13/03/2024 18:10 CET Franco Martelli ha scritto: > > > On 13/03/24 at 17:51, fran...@libero.it wrote:

Re: Ethernet not working on a Dell notebook

On 13/03/24 at 17:51, fran...@libero.it wrote: Sorry what is the procedure to add "iommu=soft amd_iommu" to the kernel command-line? It is the first time I work with kernel. I went to /etc/default/grub and on the line GRUB_CMDLINE_LINUX_DEFAULT I have ="quiet splash" Have I to add ? Thanks for

Re: Ethernet not working on a Dell notebook

'managed') mar 11 16:48:25 debian NetworkManager[626]: [1710172105.9482] manager: NetworkManager state is now CONNECTING mar 11 16:48:25 debian NetworkManager[626]: [1710172105.9850] device (wlp18s0b1): set-hw-addr: reset MAC address to C4:17:FE:D7:54:E2 (preserve) mar 11 16:48:26 debian Netw

Re: Ethernet not working on a Dell notebook

Am 13.03.2024 um 16:14:22 Uhr schrieb fran...@libero.it: > mar 13 11:55:20 debian NetworkManager[569]: [1710327320.4031] > dhcp4 (en> mar 13 11:55:20 debian NetworkManager[569]: > [1710327320.4152] dhcp4 (en> Use journalctl --no-pager -t NetworkManager to get the complete lines. -- Gruß Marc

Re: Ethernet not working on a Dell notebook

Asking to CahtGPT was just for curiosity hoping for an eventual addressing where to go About commands you suggest, hereunder the answer: Active: failed (Result: exit-code) since Wed 2024-03-13 11:54:42 CET; 4h 1> Docs: man:interfaces(5) Process: 536 ExecStart=/sbin/ifup -a --r

Re: Ethernet not working on a Dell notebook

On 13/03/2024 21:52, Franco Martelli wrote: Do you have configured both NetworkManager and Debian /etc/network/interfaces? They cannot coexist, They can coexist. NetworkManager in default configuration ignores interfaces under control of ifupdown (/etc/network/interfaces). Detailed messages

Re: Ethernet not working on a Dell notebook

On 13/03/24 at 10:19, fran...@libero.it wrote: Hello, thanks for your answers. I used the cable with other notebooks and it worked. In any case I used another cable to test it, but I had the same reactions, no connection! Today I had to give the command 3 times before having a connection...

Re: Ethernet not working on a Dell notebook

Here the "long" output of the 2 requested commands: [0.306974] pci :14:00.0: proprietary Ricoh MMC controller disabled (via FireWire function) [0.306975] pci :14:00.0: MMC cards are now supported by standard SDHCI controller [0.306977] pci :14:00.0: [1180:e822] type 00 cla

Re: Ethernet not working on a Dell notebook

Am 13.03.2024 um 10:19:04 Uhr schrieb fran...@libero.it: > So I give a try to ask to ChatGPT what does it mean that command and > this was the answer: This was already clear. The question is now: Why does autoneg fail? Please check dmesg and journalctl for any messages from Networkmanager. --

Re: Ethernet not working on a Dell notebook

On 12/03/2024 15:11, fran...@libero.it wrote: 13:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03) lspci -vnn -s 13:00.0 should give more detailed info concerning your network adapter. Finally while trying to find the

Re: Ethernet not working on a Dell notebook

Am 12.03.2024 um 10:17:05 Uhr schrieb fran...@libero.it: > it is connected via a Switch (Netgear) to the modem-router. > If I use this cable with other computers it works without problems. Please test another cable and another switch if available. We need to track down the problem. -- Gruß Mar

Re: Ethernet not working on a Dell notebook

fran...@libero.it writes: > sudo mii-tool enp19s0 -F 10baseT-FD > > The problem is that every time I shut off the notebook Ito have ethernet > connection again I have to give that command by terminal. Is > there the possibility to make default this ethernet module? Thanks and regards You can spe

Re: Ethernet not working on a Dell notebook

Am 12.03.2024 um 09:11:20 Uhr schrieb fran...@libero.it: > Finally while trying to find the solution I tried this command and > after some seconds I was online: > > sudo mii-tool enp19s0 -F 10baseT-FD That seems to be an autoneg problem. Please tell us more about your cabling (direct, via socke

Re: Ethernet device names change Bullseye => Bookworm. How to assign unchanging name to device?

20.06.23, 08:36 +0200, Rick Thomas: I've been upgrading my machines Bullseye => Bookworm recently. In a few of these upgrades, the name of the ethernet device changed. (E.g. enP2p32s15f0 => enP2p0s15f0) This required changes to /etc/network/interfaces in order to start up the interface. T

Re: Ethernet Performance Problem Solved

On 9/6/2022 5:00 PM, Marc Auslander wrote: I have an Realtek Semiconductor Co., Ltd. RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller (rev 02) Subsystem: Acer Incorporated [ALI] RTL810xE PCI Express Fast Ethernet controller There is also a Realtek Semiconductor Co., Ltd. Device 8161 (

Re: Ethernet Performance Problem

Marc Auslander wrote: > I have an Realtek Semiconductor Co., Ltd. RTL8101/2/6E PCI Express > Fast/Gigabit Ethernet controller (rev 02) Subsystem: Acer Incorporated [ALI] > RTL810xE PCI Express Fast Ethernet controller > > There is also a Realtek Semiconductor Co., Ltd. Device 8161 (rev 15) >     

Re: ethernet cfg via kernel cmdline (was: Buster without systemd?)

On Mi, 25 mar 20, 18:52:25, Andrei POPESCU wrote: > On Mi, 25 mar 20, 12:21:49, Felix Miata wrote: > > Andrei POPESCU composed on 2020-03-25 17:45 (UTC+0200): > > > > > $ cat /proc/cmdline > > > ip=192.168.1.64::192.168.1.1::a64p:eth0:off root=LABEL=a64p rootwait rw > > > rootflags=noatime > > >

Re: ethernet cfg via kernel cmdline (was: Buster without systemd?)

On Mi, 25 mar 20, 12:21:49, Felix Miata wrote: > Andrei POPESCU composed on 2020-03-25 17:45 (UTC+0200): > > > $ cat /proc/cmdline > > ip=192.168.1.64::192.168.1.1::a64p:eth0:off root=LABEL=a64p rootwait rw > > rootflags=noatime > > > The interface is not even up after start and if I bring it up

Re: ethernet cfg via cmdline (was: Buster without systemd?)

Andrei POPESCU composed on 2020-03-25 17:45 (UTC+0200): > $ cat /proc/cmdline > ip=192.168.1.64::192.168.1.1::a64p:eth0:off root=LABEL=a64p rootwait rw > rootflags=noatime > The interface is not even up after start and if I bring it up manually > with 'ip' it doesn't have any IPv4 address confi

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 "/etc/udev/rul

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 > "/etc/systemd/network/*.

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

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 ot

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 bit

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 you

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 so

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 M

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" D

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 define

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 defin

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

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 Etherne

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 s

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 wi

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 known

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 im

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 fo

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 fund

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 h

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

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 a

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

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 anything

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 eas

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 over

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 (typically

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 incr

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 a

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 the

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 abou

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 d

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 port

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 doubt

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 writ

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' indicat

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 n

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 pre

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 upgr

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 myse

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 devic

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 call

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,

Re: Ethernet Connection Dropped Again

On Wed, Feb 14, 2018 at 06:44:55PM -0500, Thomas George wrote: > Starting last month the PC Ethernet connection is sometimes not made > atbootup or is occasionally lost. When this happens the only way I havefound > to re-establish the connection is to turn the TP-Link AC1750 router off and > on aga

Re: Ethernet Connection Dropped Again

On Wed 14 Feb 2018 at 18:44:55 -0500, Thomas George wrote: > Starting last month the PC Ethernet connection is sometimes not made > atbootup or is occasionally lost. When this happens the only way I havefound > to re-establish the connection is to turn the TP-Link AC1750 router off and > on again.

Re: Ethernet is not started at boot

On 08/02/18 01:22 AM, Erik Christiansen wrote: On 08.02.18 08:42, to...@tuxteam.de wrote: On Thu, Feb 08, 2018 at 01:36:41PM +1100, Erik Christiansen wrote: [...] [...] Fastidious fusspotting on minor terminology matters [...] Yikes :-) May I steal this one when I need it badly? It's e

Re: Ethernet is not started at boot

On 08/02/18 15:36, Erik Christiansen wrote: >> Please don't use "class B" to mean /16. Firstly, it's decades out of >> date, and secondly, that range was never in the class B section. > I'm decades out of date too, so it's apt. The intended audience can > probably discern the message that a broader

  1   2   3   4   5   6   7   >