On 12/04/2025 07:16, coffeeforblood.pardon117 wrote:
I performed some very basic testing using a Debian 12.8.0 Live CD.
Likely nobody will be interested in minor bugs for versions released a
couple of years ago. At current moment it is better to try trixie weekly
builds. Upstream developers o
On 12/4/25 11:27, Max Nikulin wrote:
I had both running without conflicts on my old laptop with
Ubuntu-20.04 LTS focal. I hope, Debian does not differ in this case.
Just set what devices each daemon should ignore.
Ethernet and WiFi were under control of NetworkManager (to have tray
indicato
On 12/04/2025 09:58, jeremy ardley wrote:
The thing to remember is you can't have NetworkManager and systemd-
networkd running at the same time.
I had both running without conflicts on my old laptop with Ubuntu-20.04
LTS focal. I hope, Debian does not differ in this case. Just set what
device
On 12/4/25 08:16, coffeeforblood.pardon...@slmail.me wrote:
The short version is that if the behavior with "Connect Automatically" and "Make
available to other users" is down to NetworkManager, then I sympathize with the suggestions
to migrate from it to systemd-networkd. If someone could po
Thank you for the continued responses. I performed some very basic testing
using a Debian 12.8.0 Live CD. The results were confusing and highlighted some
issues with the creation of network profiles in general, at least from my point
of view.
The short version is that if the behavior with "Con
On Mon 07 Apr 2025 at 21:34:42 (+0200), coffeeforblood.pardon...@slmail.me
wrote:
>
> > I am curious what nmcli subcommand reports when the cable is plugged in,
> > but the connection has not activated manually.
> >
> Should I pursue the strange behavior of needing to have "Make available to
>
On Mon, Apr 07, 2025 at 09:34:42PM +0200, coffeeforblood.pardon...@slmail.me
wrote:
Should I pursue the strange behavior of needing to have "Make available
to others users" enabled for the "Connect Automatically" setting to be
respected, in case there is a bug, or close this issue as solved? I'
On 08/04/2025 02:34, coffeeforblood.pardon117 wrote:
I am curious what nmcli subcommand reports when the cable is plugged in,
but the connection has not activated manually.
Should I pursue the strange behavior of needing to have "Make available
to others users" enabled for the "Connect Automat
On 8/4/25 11:18, Titus Newswanger wrote:
FWIW, I generally don't get along with NetworkManager on server
installations and end up uninstalling it and running either
systemd-networkd or netplan. I just got done with a server install
where the network was not coming up until after I logged into
On 4/7/25 14:34, coffeeforblood.pardon...@slmail.me wrote:
Should I pursue the strange behavior of needing to have "Make available to others users"
enabled for the "Connect Automatically" setting to be respected, in case there is a bug,
or close this issue as solved? I'm happy either way.
FW
> I am curious what nmcli subcommand reports when the cable is plugged in, but
> the connection has not activated manually.
>
Should I pursue the strange behavior of needing to have "Make available to
others users" enabled for the "Connect Automatically" setting to be respected,
in case there
On Fri, Apr 4, 2025 at 10:17 PM wrote:
>
> On Thu, Apr 4, 2025 at 11:56 PM Lee wrote:
>
> > Can you try it with Make available to other users ON
>
> Toggling "Make available to other users" to ON solves the problem! First I
> tested this with the built-in Ethernet adapter. After this was successf
On 05/04/2025 07:33, coffeeforblood.pardon117 wrote:
I think there is still the question of why this setting must be ON for
this to work properly. I followed the steps suggested by Max Nikulin and
I think there is something interesting in the output of 'journalctl -f'.
I do not think, GNOME ap
On Thu, Apr 4, 2025 at 11:56 PM wrote:
> Can you try it with Make available to other users ON
Toggling "Make available to other users" to ON solves the problem! First I
tested this with the built-in Ethernet adapter. After this was successful I
configured this to ON for the other adapters and
On Thu, Apr 3, 2025 at 9:32 PM wrote:
>
> Background Information
> ===
>
> Debian 12 Bookworm has been freshly installed on a laptop. The laptop is
> functioning as a simple home server and has three Ethernet devices, two USB
> Ethernet adapters and a built-in Ethernet adapte
On Fri, Apr 04, 2025 at 05:19:08PM +0800, jeremy ardley wrote:
Off Topic I just did a 1 year diploma in advanced networking. I
couldn't even comprehend why the still had crossover cables in the
lab. Perhaps to accommodate pre-2000 CISCO switches?
cisco was one of the companies that was late to
On 04/04/2025 05:56, coffeeforblood.pardon117 wrote:
Here is the output of 'ip addr' for USB Ethernet Adapter #1 under
different circumstances:
You have not written it explicitly, but almost certainly you use
NetworkManager. That is why its configuration should be inspected
nmcli
n
On 4/4/25 17:06, Jeffrey Walton wrote:
I would not be surprised to learn that some inexpensive ethernet
controllers lacked some features, like Auto MDI-X, since it is an
optional feature of the 1000BASE-T standard.
For 1000BASE-T I would be very surprised if that was the case as it uses
all
On Fri, Apr 4, 2025 at 12:52 AM jeremy ardley wrote:
>
> On 4/4/25 09:38, Jeffrey Walton wrote:
> > It sounds like the client is connected directly to the server via
> > ethernet, presumably without a cross-over ethernet cable. So both
> > ethernet ports would need to auto-sense the configuration.
On Thu, Apr 03, 2025 at 09:38:29PM -0400, Jeffrey Walton wrote:
... when a cable from the server is connected to the Ethernet port
of a client device, the Debian server will automatically recognize
the new physical connection and then automatically activate that
connection.
It sounds
On 4/4/25 09:38, Jeffrey Walton wrote:
It sounds like the client is connected directly to the server via
ethernet, presumably without a cross-over ethernet cable. So both
ethernet ports would need to auto-sense the configuration.
Can you run the same experiment with a hub or switch in between?
On Thu, Apr 3, 2025 at 9:32 PM wrote:
>
> Background Information
> ===
>
> Debian 12 Bookworm has been freshly installed on a laptop. The laptop is
> functioning as a simple home server and has three Ethernet devices, two USB
> Ethernet adapters and a built-in Ethernet adapte
On 4/4/25 06:56, coffeeforblood.pardon...@slmail.me wrote:
I noted that systemd-networkd service is not running by default. For testing
purposes I enabled and started this service, but there was no improvement.
systemd-networkd is a competitor to NetworkManager. You need to run one
or the
On Fri, 4 Apr 2025 00:56:05 +0200 (CEST)
coffeeforblood.pardon...@slmail.me wrote:
> Is it normal for 'systemd-networkd' not to be running by default on a
> fresh installation of Debian 12, as a general rule? I disabled it
> again after troubleshooting this problem.
Yes, it is.
Installation does
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
> 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
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
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
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
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:
~#
8 CET
> Oggetto: Re: Ethernet not working on a Dell notebook
>
>
> Am 14.03.2024 schrieb fran...@libero.it:
>
> > auto eth0
>
> remove that.
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
Am 14.03.2024 schrieb fran...@libero.it:
> auto eth0
remove that.
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
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
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?
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
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
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:
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
'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
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
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
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
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...
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
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.
--
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
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
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
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
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
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 (
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)
>
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
> >
>
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
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
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.
> > [...]
>
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
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/*.
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,
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
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
--
On 1/31/20 2:42 PM, Reco wrote:
> As a programmer, you should be familiar with it :)
Very. And misconfigs too...
--
Glenn English
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.
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
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.
> >
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
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
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
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
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
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
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
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
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).
>
>
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
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
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
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
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
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
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
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
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
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
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
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!
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
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
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
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
> 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
> 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.
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
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
> 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
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
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
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
1 - 100 of 671 matches
Mail list logo
