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-devel@
On 05/11/2015 05:53 AM, Marco d'Itri wrote:
On May 08, Martin Pitt mp...@debian.org 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:
On Jun 26, Thomas Goirand z...@debian.org 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
Martin Pitt mpitt@... 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
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
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 problem, but
On May 08, Martin Pitt mp...@debian.org 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
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 to
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 cable
[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/iface |grep NAME says
about these.
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
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
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 for
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
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
On Fri, 8 May 2015 00:33:58 -0700
Josh Triplett j...@joshtriplett.org 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
Martin Pitt mp...@debian.org 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
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 adapter.
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
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
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.
--
.''`. Josselin
21 matches
Mail list logo
