On 06/26/2015 11:14 AM, Marco d'Itri wrote:
>>> I believe that firmware-based device names work well enough in practice
>>> since RHEL 7 uses them by default: I tend to trust a market-based
>>> approach to maintenability more than anecdote from a very selected
>>> population like the debian-deve
On Jun 26, Thomas Goirand wrote:
> > Actually it requires us to keep maintaining the
> > Revert-udev-network-device-renaming patch as long as there will be
> > systems with a 70-persistent-net.rules file renaming eth* to eth*.
> The other solution would be to upstream that patch (maybe as a ker
On 05/11/2015 05:53 AM, Marco d'Itri wrote:
> On May 08, Martin Pitt wrote:
>
>> I propose to retire [mac], i. e. drop
>> /lib/udev/rules.d/75-persistent-net-generator.rules and enable
>> [ifnames] by default.
> I see a large enough consensus about switching by default to ifnames,
FWIW: I don't.
Martin Pitt writes:
> - [mac] For many many years our we have installed an udev rule
>/lib/udev/rules.d/75-persistent-net-generator.rules which on first
>boot creates a MAC address → current name mapping and writes
>/etc/udev/rules.d/70-persistent-net.rules.
Hm, that usually worked
On May 13, "D. Jared Dominguez" wrote:
> >- it does not seem to me to provide any benefit over the firmware-based
> > names since in practice both would use by default an interface index
> > in the common case
> Firmware based in what sense? From the biosdevname readme, biosdevname uses:
> PCI Co
Maybe biosdevname would be nice to have, but:
- somebody needs to actually maintain it in Debian
I actually had it ready to upload, but then given the approach RHEL 7
took and the general trend towards systemd-based approaches, I held off.
If there is interest, though, I'm happy to maintain bi
On Sat, May 09, 2015 at 02:49:35AM -0500, peter green wrote:
The main downside is that by nature the device names are not familiar
to current admins yet. For BIOS provided names you get e. g. ens0, for
PCI slot names enp1s1 (ethernet) or wlp3s0 (wlan). But that's a
necessary price to pay (biosde
Hello,
Karsten Merker [2015-05-11 20:22 +0200]:
> >From what Ben Hutchings has described in
> <1431294933.2233.66.ca...@decadent.org.uk>, the race condition
> could easily be avoided with the current codebase by simply not
> using "eth" as the prefix, but e.g. "en".
Right, that would solve one pr
On May 11, Ben Hutchings wrote:
> For ARM (and any other architecture using Device Tree) the on-board
> indices should be specified as aliases 'ethernet0', 'ethernet1', etc.
Is this something that I can experiment on by patching just the device
tree definition or does it happen in the driver?
Do
On Mon, 2015-05-11 at 05:53 +0200, Marco d'Itri wrote:
[...]
> It will be even worse when not even ID_NET_NAME_PATH is defined (e.g. on
> my Allwinner-based ARM computer), which means that interfaces will get
> a mac-based name like enx028909xx.
[...]
For ARM (and any other architecture usin
Hey Marco,
Marco d'Itri [2015-05-11 5:53 +0200]:
> I am not sure that we really need to retire 75-persistent-net-generator
> right now: the annoying part to maintain is the kernel patch which we
> will need anyway for at least a couple of releases
Which kernel patch? I think all of this ought
On May 08, Marc Haber wrote:
> That would mean changing local code to _both_ handle en* and eth*,
> which is (a) a surprise and (b) unsatisfying in _my_ personal opinion.
>
> I'd rather have it fully and consistently or not at all.
"Not at all" is going to be harder and harder to support, so we
On May 08, Martin Pitt wrote:
> I propose to retire [mac], i. e. drop
> /lib/udev/rules.d/75-persistent-net-generator.rules and enable
> [ifnames] by default.
I see a large enough consensus about switching by default to ifnames,
and I believe that the few people who want MAC-based names for USB
[dropping d-devel@ as recipient]
Quoting Martin Pitt (2015-05-09 11:26:14)
> [1] I don't have USB-ethernet devices myself; if you have one, please
> get in touch with me, I'd like to investigate how they look like in
> udev, and what "udevadm test /sys/class/net/ |grep NAME" says
> about these.
Hey Paul,
Paul Wise [2015-05-09 16:15 +0800]:
> Is there a tool to list interfaces based on their characteristics?
> Right now at $work our initial setup code does glob eth* in
> /sys/class/net in order to setup a bond interface using all NICs, so
> network works no matter which NIC one plugs a ca
Bjørn Mork [2015-05-08 16:13 +0200]:
> PCI buses can be and are hotplugged, similar to network devices.
Yes, that's certainly a valid point. It's not unanimously clear how
you define the "identity" of an interface, whether it's more like "by
location" or "by MAC address". There are pros and cons f
Is there a tool to list interfaces based on their characteristics?
Right now at $work our initial setup code does glob eth* in
/sys/class/net in order to setup a bond interface using all NICs, so
network works no matter which NIC one plugs a cable into. It sounds
like this proposal would break that
The main downside is that by nature the device names are not familiar
to current admins yet. For BIOS provided names you get e. g. ens0, for
PCI slot names enp1s1 (ethernet) or wlp3s0 (wlan). But that's a
necessary price to pay (biosdevname names look similar).
The stability of these names appea
On Fri, May 08, 2015 at 10:04:36PM +0200, Karsten Merker wrote:
> On Fri, May 08, 2015 at 12:29:03PM -0700, j...@joshtriplett.org wrote:
> > On Fri, May 08, 2015 at 09:06:25PM +0200, Karsten Merker wrote:
> > > On Fri, May 08, 2015 at 10:50:30AM -0700, Josh Triplett wrote:
> > > > Karsten Merker wr
On Fri, May 08, 2015 at 09:06:25PM +0200, Karsten Merker wrote:
> On Fri, May 08, 2015 at 10:50:30AM -0700, Josh Triplett wrote:
> > Karsten Merker wrote:
> > > while this probably works resonably well for (semi-)fixed devices
> > > like onboard-NICs and PCI/PCIe cards, it results in a completely
>
Just my 0.02$ against using the BIOS method.
I have and Do see inconsistent bios vendor naming used from release to
release of their Firmware updates. I have had to fix HP Propliants servers
numerous time due to a firmware update changing the number and/or order of
SATA ports, PCI and other things
Le vendredi 08 mai 2015 à 07:59 +0200, Martin Pitt a écrit :
> Proposal
>
> I propose to retire [mac], i. e. drop
> /lib/udev/rules.d/75-persistent-net-generator.rules and enable
> [ifnames] by default.
Yes, yes, yes, please.
Let’s get rid of that horrible thing.
--
.''`. Josseli
Hi,
Karsten Merker:
> while this probably works resonably well for (semi-)fixed devices
> like onboard-NICs and PCI/PCIe cards, it results in a completely
> unsuitable behaviour with pluggable devices such as USB network
> adapters.
Why?
I can envision two likely scenarios for using a USB adapte
Martin Pitt writes:
> - [ifnames] For about two years (since 197) upstream's udev has a
>builtin persistant name generator which checks firmware/BIOS
>provided index numbers or slot names (like biosdevname), falls back
>to slot names (PCI numbers,
Note that this makes the same bogus
Hello Konstantin,
Konstantin Khomoutov [2015-05-08 13:08 +0300]:
> Is it possible to provide a tool (a shell script?) that would print out
> the new would-be name of the interface provided by the user so that it
> would be possible to migrate remote systems only accessible via SSH?
The closest th
On Fri, 8 May 2015 00:33:58 -0700
Josh Triplett wrote:
> > I propose to retire [mac], i. e. drop
> > /lib/udev/rules.d/75-persistent-net-generator.rules and enable
> > [ifnames] by default.
[...]
> Having spent a non-trivial amount of time fighting
> persistent-net.rules on various systems, I'd v
Martin Pitt wrote:
> Proposal
>
> I propose to retire [mac], i. e. drop
> /lib/udev/rules.d/75-persistent-net-generator.rules and enable
> [ifnames] by default.
>
> This will provide the new stable interface names for all new
> installations, stop the different handling of server/client,
Martin Pitt [2015-05-08 7:59 +0200]:
> Details about [mac]
> ---
> [...]
> * It requires a writable /etc/udev/rules.d/ for persistantly storing
> the assignment. We don't want/have that with system-image
> (touch/snappy).
Sorry, these are Ubuntu specific terms, forgot to
28 matches
Mail list logo
