Le 02/09/2017 à 15:45, Erik Christiansen a écrit :
On 02.09.17 14:49, Didier Kryn wrote:
Le 02/09/2017 à 08:25, Erik Christiansen a écrit :
Looking at "man ifrename", we see:
-u Enable udev output mode. This enables proper integration of ifrename
in the udev framework, udevd(8) will use i
On 02.09.17 14:49, Didier Kryn wrote:
> Le 02/09/2017 à 08:25, Erik Christiansen a écrit :
> > Looking at "man ifrename", we see:
> >
> > -u Enable udev output mode. This enables proper integration of ifrename
> > in the udev framework, udevd(8) will use ifrename to assign interface
> > na
Le 02/09/2017 à 08:25, Erik Christiansen a écrit :
On 21.08.17 01:38, Daniel Reurich wrote:
Hi,
We discussed a few weeks back in a dev meeting whether or not to revert
to jessie like naming scheme for ethernet interfaces by default.
The eudev package (currently found in the experimental repos
Hi there
On 22/08/17 11:42, Didier Kryn wrote:
Le 22/08/2017 à 09:10, Narcis Garcia a écrit :
persistent-net.rules allows 100% definitive names.
Definitive but with a possible mess. A new eth1 could be created by
the kernel in the same time eth0 is renamed to eth1 by Udev. The race
p
On 21.08.17 01:38, Daniel Reurich wrote:
> Hi,
>
> We discussed a few weeks back in a dev meeting whether or not to revert
> to jessie like naming scheme for ethernet interfaces by default.
>
> The eudev package (currently found in the experimental repos and at
> https://git.devuan.org/devuan-pac
Le 22/08/2017 à 09:10, Narcis Garcia a écrit :
persistent-net.rules allows 100% definitive names.
Definitive but with a possible mess. A new eth1 could be created by
the kernel in the same time eth0 is renamed to eth1 by Udev. The race
problem pointed by Adam.
Didier
___
El 22/08/17 a les 02:48, Alessandro Selli ha escrit:
> On Mon, 21 Aug 2017 at 10:32:43 +0200
> Narcis Garcia wrote:
>
> [...]
>
>> This logic does not guarantee 100% predictable naming (think about
>> removable NICs), but gives enough confort to a sysadmin deals any with
>> situation.
>
> If
Quote: Simon Hobson wrote:
> I suppose that one REALLY good way to fix the problem (at least in the
> server & desktop areas) is actually to undo a lot of "progress" and make
> all driver and service initiation strictly linear. Ie, do away with all
> this parallelism and make all drivers be loaded
On Sun, 20 Aug 2017 at 22:24:58 -0400
Steve Litt wrote:
> As a wee lad, my mentors told me never to put two of the same model
> NICs in a computer, because which one became eth0 and which became eth1
> would be indeterminate from boot to boot.
What about the numerous cases when you cannot chos
On Mon, 21 Aug 2017 at 12:56:24 +0200
Didier Kryn wrote:
> In any case the admin must either hack /etc/network/interfaces or
> the udev rules. But I think this little inconveniency is better than the
> meaningless device names promoted by Systemd people.
And the other network cards can
>
> As a wee lad, my mentors told me never to put two of the same model
> NICs in a computer, because which one became eth0 and which became eth1
> would be indeterminate from boot to boot. That's horrible, and that *is*
> solved by the systemd naming scheme.
I thought that issue had been dealt w
On Mon, 21 Aug 2017 at 10:32:43 +0200
Narcis Garcia wrote:
[...]
> This logic does not guarantee 100% predictable naming (think about
> removable NICs), but gives enough confort to a sysadmin deals any with
> situation.
If it's not 100% predictable and configurable by the sysadmin then it doe
On Mon, 21 Aug 2017 at 09:22:22 +0100
Simon Hobson wrote:
[...]
> I suppose that one REALLY good way to fix the problem (at least in the
> server & desktop areas) is actually to undo a lot of "progress" and make
> all driver and service initiation strictly linear. Ie, do away with all
> this par
On Sun, Aug 20, 2017 at 09:30:00PM -0700, Rick Moen wrote:
> Let me try to draw a distinction with some nuance, here: To the best of
> my knowledge -- and my knowledge might be incomplete or unaware of some
> new developments -- 'spontaneous' network device renaming, just like
> spontaneous mass s
On 21-08-17 06:30, Rick Moen wrote:
Quoting Steve Litt (sl...@troubleshooters.com):
As a wee lad, my mentors told me never to put two of the same model
NICs in a computer, because which one became eth0 and which became eth1
would be indeterminate from boot to boot.
It's funny you'll say that,
On Mon, 21 Aug 2017 07:26:04 -0700
Rick Moen wrote:
> > On Sun, 20 Aug 2017 21:30:00 -0700 Rick Moen
> > wrote:
> >
> > > However_, even given that, in my experience any reshuffle USB would
> > > add to the _existing_ devices' node assignments would occur only at
> > > reboot time _if_ you left
Quoting Renaud OLGIATI (ren...@olgiati-in-paraguay.org):
> On Sun, 20 Aug 2017 21:30:00 -0700 Rick Moen
> wrote:
>
> > However_, even given that, in my experience any reshuffle USB would
> > add to the _existing_ devices' node assignments would occur only at
> > reboot time _if_ you left the USB
Le 21/08/2017 à 12:56, Didier Kryn a écrit :
Le 20/08/2017 à 18:57, Renaud (Ron) OLGIATI a écrit :
On Sun, 20 Aug 2017 16:38:18 +0100
Rowland Penny wrote:
As far as I am aware, each network device should have a different MAC,
couldn't this be used to identify which device is which ?
Could, bu
Le 20/08/2017 à 18:57, Renaud (Ron) OLGIATI a écrit :
On Sun, 20 Aug 2017 16:38:18 +0100
Rowland Penny wrote:
As far as I am aware, each network device should have a different MAC,
couldn't this be used to identify which device is which ?
Could, but whenever you have to change a NIC after a t
On Sun, 20 Aug 2017 21:30:00 -0700
Rick Moen wrote:
> However_, even given that, in my experience any reshuffle
> USB would add to the _existing_ devices' node assignments would occur
> only at reboot time _if_ you left the USB device plugged in.
Personal experience: I run an IPCop box as a fir
Quoting marc (marc...@welz.org.za):
> Like Rick I haven't encountered a spontaneous device name
> re-order in the wild.
Just to be skeptical for a moment of my own wording, I probably
_slightly_ overstated (at least by implication) what I've observed over
the decades, here:
I understood tha
Edward Bartolo wrote:
> Therefore, if I were in a position to take decisions I would
> not expect a computer to know what I need. However, a computer should
> have no difficulty processing data. A decent OS should save a map of
> how hardware is connected, somewhat like a hardware tree with all
>
El 20/08/17 a les 21:53, fsmithred ha escrit:
> On 08/20/2017 10:27 AM, Adam Borowski wrote:
>>
>> * systemd-udev's promise of providing _stable_ names didn't deliver. They
>> still change on major kernel upgrades, and sometimes on every boot.
>> And their chosen naming is utterly insane (wlx
Steve Litt wrote:
> As a wee lad, my mentors told me never to put two of the same model
> NICs in a computer, because which one became eth0 and which became eth1
> would be indeterminate from boot to boot. That's horrible, and that *is*
> solved by the systemd naming scheme.
Except when it isn't
If Devuan decides to use a different device name naming scheme apart
from the one discussed several months ago (a year ago?), it will
result in breaking simple-netaid-backend and simple-netaid-gui. I used
the naming scheme en* for ethN and wl* for wlanN.
Regarding this discussion what I have to sa
So another vote for keeping the eth0/wlan0 scheme and
not renaming devices in userspace.
Like Rick I haven't encountered a spontaneous device name
re-order in the wild.
However, some time ago the authors of the reverse engineered
nvidia ethernet driver (was it forcedeth?) noticed they had
decode
Quoting Steve Litt (sl...@troubleshooters.com):
> As a wee lad, my mentors told me never to put two of the same model
> NICs in a computer, because which one became eth0 and which became eth1
> would be indeterminate from boot to boot.
It's funny you'll say that, and not just because we're both o
On 20.08.17 22:24, Steve Litt wrote:
> #FOR SINGLE WIFI AND ETH DEVICES
> $eth0=enop1
> $wlan0=wl52po45tldnr
If we can script the decryption of the obfuscating nonsense, then
developers ought to not be so much less competent that they can't do it
at the outset. (I did my 30 years on bare iron (emb
On 20.08.17 16:09, Gregory Nowak wrote:
> On Mon, Aug 21, 2017 at 01:38:00AM +1200, Daniel Reurich wrote:
> > This would lead network interface names default to the old "eth0" or
> > "wlan0" scheme, rather than the new(?) "enp0s3"-like scheme. It implies
> > having "net.ifnames=1" in the kernel cmd
On Sun, 20 Aug 2017 15:53:40 -0400
fsmithred wrote:
> Yeah, the name on a usb dongle is insane. I didn't stick with it long
> enough to figure out if that number comes from somewhere or is random.
LOL, I stuck a wifi dongle into a USB hub plugged into a USB port, and
the NIC name was about 10 c
On Sun, 20 Aug 2017 16:38:18 +0100
Rowland Penny wrote:
> On Sun, 20 Aug 2017 17:18:13 +0200
> Adam Borowski wrote:
> > You can't safely rename to eth0/wlan0. At bootup, when an interface
> > is being cold/hot-plugged, an *udev script is run. When that script
> > decides that the interface th
On Mon, Aug 21, 2017 at 01:38:00AM +1200, Daniel Reurich wrote:
> This would lead network interface names default to the old "eth0" or
> "wlan0" scheme, rather than the new(?) "enp0s3"-like scheme. It implies
> having "net.ifnames=1" in the kernel cmdline to get the "enp0s3"-like
> scheme and not t
On Sun, 20 Aug 2017 at 17:24:30 +0200
viverna wrote:
> il devuanizzato Daniel Reurich il 20/08/17 alle
> ore 15:38 ha scritto:
> > This would lead network interface names default to the old "eth0" or
> > "wlan0" scheme, rather than the new(?) "enp0s3"-like scheme. It implies
> > having "net.ifna
Adam Borowski wrote:
> There was a lengthy thread on debian-devel recently. While it did include
> the usual shout-fest, there's also a good amount of actually relevant info,
> thus I'd recommend reading it.
>
> It starts at:
> https://lists.debian.org/debian-devel/2017/07/msg00126.html
It is
On 08/20/2017 10:27 AM, Adam Borowski wrote:
>
> * systemd-udev's promise of providing _stable_ names didn't deliver. They
> still change on major kernel upgrades, and sometimes on every boot.
> And their chosen naming is utterly insane (wlxf81a671bcfae, WTF?).
> Only systemd proponents st
> Date: Sun, 20 Aug 2017 17:24:30 +0200
> From: viverna
>
> il devuanizzato Daniel Reurich il 20/08/17 alle ore
> 15:38 ha scritto:
>> This would lead network interface names default to the old "eth0" or
>> "wlan0" scheme, rather than the new(?) "enp0s3"-like scheme. It implies
>> having "net.i
On Sun, Aug 20, 2017 at 7:08 PM, Daniel Reurich wrote:
> Hi,
>
> We discussed a few weeks back in a dev meeting whether or not to revert
> to jessie like naming scheme for ethernet interfaces by default.
>
> The eudev package (currently found in the experimental repos and at
> https://git.devuan.o
El 20/08/17 a les 16:48, Lars Noodén ha escrit:
> On 08/20/2017 04:38 PM, Daniel Reurich wrote:
>> We discussed a few weeks back in a dev meeting whether or not to revert
>> to jessie like naming scheme for ethernet interfaces by default.
>
> My only interest would be consistency: that the same ph
On Sun, 20 Aug 2017 16:38:18 +0100
Rowland Penny wrote:
> As far as I am aware, each network device should have a different MAC,
> couldn't this be used to identify which device is which ?
Could, but whenever you have to change a NIC after a thunderstorm you are
buggered...
Cheers,
Ron.
--
On Sun, 20 Aug 2017 at 16:38, Daniel Reurich
wrote:
> Hi,
>
> We discussed a few weeks back in a dev meeting whether or not to revert
> to jessie like naming scheme for ethernet interfaces by default.
>
> The eudev package (currently found in the experimental repos and at
> https://git.devuan.org
On Sun, 20 Aug 2017 17:18:13 +0200
Adam Borowski wrote:
> On Sun, Aug 20, 2017 at 03:45:08PM +0100, Rowland Penny wrote:
> > On Sun, 20 Aug 2017 16:27:26 +0200
> > Adam Borowski wrote:
> [my snip:]
> > > * any renames to "eth0"/"wlan0" are a losing idea, as a new
> > > interface can appear at an
il devuanizzato Daniel Reurich il 20/08/17 alle ore
15:38 ha scritto:
> This would lead network interface names default to the old "eth0" or
> "wlan0" scheme, rather than the new(?) "enp0s3"-like scheme. It implies
> having "net.ifnames=1" in the kernel cmdline to get the "enp0s3"-like
> scheme a
On Sun, Aug 20, 2017 at 03:45:08PM +0100, Rowland Penny wrote:
> On Sun, 20 Aug 2017 16:27:26 +0200
> Adam Borowski wrote:
[my snip:]
> > * any renames to "eth0"/"wlan0" are a losing idea, as a new interface
> > can appear at any moment, clashing with what you just tried to rename
> > to. Several
On 08/20/2017 04:38 PM, Daniel Reurich wrote:
> We discussed a few weeks back in a dev meeting whether or not to revert
> to jessie like naming scheme for ethernet interfaces by default.
My only interest would be consistency: that the same physical device
always gets the same name, even if some of
On Sun, 20 Aug 2017 16:27:26 +0200, Adam wrote in message
<20170820142726.ojyrd6plsfjmc...@angband.pl>:
> But sticking with just kernel names would still be much better than
> the enp0s3 idea. It'd be _predictable_ in that 99% case; machines
> with multiple interfaces tend to be either routers (
On Sun, 20 Aug 2017 16:27:26 +0200
Adam Borowski wrote:
> On Mon, Aug 21, 2017 at 01:38:00AM +1200, Daniel Reurich wrote:
> > We discussed a few weeks back in a dev meeting whether or not to
> > revert to jessie like naming scheme for ethernet interfaces by
> > default.
> >
> > The eudev package
Le 20/08/2017 à 16:27, Adam Borowski a écrit :
Thus, I think the best long-term solution would be writing a generation,
using either *udev or ifupdown, that learns new interfaces as they come,
and names them using a single namespace that's not "eth0"/"wlan0".
In particular, a machine with only a
On Mon, Aug 21, 2017 at 01:38:00AM +1200, Daniel Reurich wrote:
> We discussed a few weeks back in a dev meeting whether or not to revert
> to jessie like naming scheme for ethernet interfaces by default.
>
> The eudev package (currently found in the experimental repos and at
> https://git.devuan.
On 21.08.17 01:38, Daniel Reurich wrote:
> This would lead network interface names default to the old "eth0" or
> "wlan0" scheme, rather than the new(?) "enp0s3"-like scheme. It implies
> having "net.ifnames=1" in the kernel cmdline to get the "enp0s3"-like
> scheme and not touching anything to get
On Mon, 21 Aug 2017 01:38:00 +1200
Daniel Reurich wrote:
> It implies
> having "net.ifnames=1" in the kernel cmdline to get the "enp0s3"-like
> scheme and not touching anything to get the "eth0" scheme.
+1
Cheers,
Ron.
--
Those of you who think you know everything
Hi,
We discussed a few weeks back in a dev meeting whether or not to revert
to jessie like naming scheme for ethernet interfaces by default.
The eudev package (currently found in the experimental repos and at
https://git.devuan.org/devuan-packages/eudev ) utilizes the same logic
like udev does wh
51 matches
Mail list logo
