* Marco d'Itri [2015-05-11 05:55]:
> 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 th
On 06/30/2015 12:14 AM, Vincent Bernat wrote:
> ❦ 29 juin 2015 22:29 +0200, Thomas Goirand :
>
So your proposal is: if the default is unusable (like above), then the
poor user has to find a way to fix that... I'm not convince that this is
what we want. I'd very much prefer a usabl
❦ 29 juin 2015 22:29 +0200, Thomas Goirand :
>>> So your proposal is: if the default is unusable (like above), then the
>>> poor user has to find a way to fix that... I'm not convince that this is
>>> what we want. I'd very much prefer a usable default.
>> Me too, but there is none that we can u
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.
On 05/17/2015 09:28 PM, Josh Triplett wrote:
> If that's a standard property of VMWare VMs, you could submit a udev
> rule that improves the default naming on such systems. I believe there
> are already some rules defining policies in that area, including
> VM-specific information.
the only thin
On Sun, May 17, 2015 at 08:03:54PM +0200, Bernd Zeimetz wrote:
> On 05/08/2015 09:28 AM, Josh Triplett wrote:
> > Marc Haber wrote:
> >> I have tried this just last week and have found it kind of
> >> unsatisfactory that it doesn't work in virtualized environments. For
> >> example, in a KVM VM wit
On 05/08/2015 09:28 AM, Josh Triplett wrote:
> Marc Haber wrote:
>> I have tried this just last week and have found it kind of
>> unsatisfactory that it doesn't work in virtualized environments. For
>> example, in a KVM VM with virtio ethernet, the network devices still
>> end up in the system as e
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
On Thu, 14 May 2015 09:07:16 +1000, Russell Stuart
wrote:
>On Wed, 2015-05-13 at 17:16 +0200, Vincent Lefevre wrote:
>> Well, having some of the network traffic (more precisely, connections
>> to machines that have an IPv6 address) re-routed to some unknown
>> machine on the local network is not a
On Wed, 2015-05-13 at 17:16 +0200, Vincent Lefevre wrote:
> Well, having some of the network traffic (more precisely, connections
> to machines that have an IPv6 address) re-routed to some unknown
> machine on the local network is not a nice feature.
>
> IMHO, such a feature should be enabled only
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
Marvin Renich wrote:
> Yes, I use ifupdown and wpasupplicant. Based on some of the threads on
> this list there are many people who love Network Manager and many who
> dislike it. I am one of the ones who dislike it. Given the fact that
> it is (or at least was recently) clearly controversial, c
On Wed, 13 May 2015 17:16:07 +0200, Vincent Lefevre
wrote:
>On 2015-05-12 22:31:43 +0200, Marc Haber wrote:
>> On Tue, 12 May 2015 17:08:33 +0200, Vincent Lefevre
>> wrote:
>> >On 2015-05-11 18:04:14 +0200, Marc Haber wrote:
>> >> In IPv6, routers advertise prefixes. If a new prefix comes, end
>>
On 2015-05-12 22:31:43 +0200, Marc Haber wrote:
> On Tue, 12 May 2015 17:08:33 +0200, Vincent Lefevre
> wrote:
> >On 2015-05-11 18:04:14 +0200, Marc Haber wrote:
> >> In IPv6, routers advertise prefixes. If a new prefix comes, end
> >> systems configured for SLAAC will allocate an IP address in th
On Tue, 12 May 2015 17:08:33 +0200, Vincent Lefevre
wrote:
>On 2015-05-11 18:04:14 +0200, Marc Haber wrote:
>> In IPv6, routers advertise prefixes. If a new prefix comes, end
>> systems configured for SLAAC will allocate an IP address in this
>> prefix and begin to use it.
>
>On this subject, end
On 2015-05-11 18:04:14 +0200, Marc Haber wrote:
> In IPv6, routers advertise prefixes. If a new prefix comes, end
> systems configured for SLAAC will allocate an IP address in this
> prefix and begin to use it.
On this subject, end systems under Debian are configured for SLAAC
by default. :-(
--
On Mon, May 11, 2015 at 07:40:38PM +0200, Karsten Merker wrote:
> On Mon, May 11, 2015 at 09:29:21AM +0100, Jonathan Dowland wrote:
> > On Fri, May 08, 2015 at 11:03:55PM +0200, Marc Haber wrote:
> > > On Fri, 8 May 2015 13:33:06 -0700, j...@joshtriplett.org wrote:
> > > >There are much better alte
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, 11 May 2015 22:37:40 +1000, Russell Stuart
wrote:
>On Mon, 2015-05-11 at 09:29 +0200, Marc Haber wrote:
>> For example, it doesn't know dependencies between Interfaces, which is
>> rather common for a server jockey (consider a VLAN on a bridge which
>> is connected to the network via a bon
On May 11, Marvin Renich wrote:
> > 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
> > interfaces can easily set NamePolicy=mac or write a custom rule.
> Huh? This thread seems to have lots of opinion
On Mon, 2015-05-11 at 09:29 +0200, Marc Haber wrote:
> For example, it doesn't know dependencies between Interfaces, which is
> rather common for a server jockey (consider a VLAN on a bridge which
> is connected to the network via a bonding device)
I haven't had to solve that example, but I have h
On Mon, 2015-05-11 at 12:16 +0200, Josselin Mouette wrote:
> Ben Hutchings wrote:
> > The NM configuration is based on MAC addresses and doesn’t care
> about
> > the interface name at all. This is the exact opposite of “handling
> > dynamic names ungracefully”.
>
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
* Marco d'Itri [150510 23:55]:
> 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
> interfaces can easily set NamePolicy=mac or write a custom rule.
Huh? This thread seems to have lots of opinions on both
Ben Hutchings wrote:
> The NM configuration is based on MAC addresses and doesn’t care about
> the interface name at all. This is the exact opposite of “handling
> dynamic names ungracefully”.
Well, that's assuming hardware that has a permanent MAC address
On Sun, May 10, 2015 at 09:04:23PM +0200, Stephan Seitz wrote:
> On Sun, May 10, 2015 at 07:09:41PM +0200, Marc Haber wrote:
> >Just for the record, an unexpected interface name change hasn't
> >happened in my professional career in more than ten years.
>
> Same here. I have never seen unexpected
On Fri, May 08, 2015 at 11:03:55PM +0200, Marc Haber wrote:
> On Fri, 8 May 2015 13:33:06 -0700, j...@joshtriplett.org wrote:
> >There are much better alternatives for most common cases.
>
> For example being?
ufw is quite nice.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
Just a quick observation: a lot of the problems people have experienced with
network interface naming is a combination of two things: both whatever
persistence scheme is in place (or not), but also the fact they *need to know a
network interface name at all*.
Many times I've wanted to express "lau
On Mon, 11 May 2015 09:29:43 +0200, Marc Haber
wrote:
>On Mon, 11 May 2015 10:18:18 +1000, Russell Stuart
> wrote:
>>I get the distinct feeling some people posting here consider ifup/down
>>"old fashioned". Granted it doesn't have a nice GUI, but from the point
>>of view of someone who deploys lo
On Mon, 11 May 2015 10:18:18 +1000, Russell Stuart
wrote:
>I get the distinct feeling some people posting here consider ifup/down
>"old fashioned". Granted it doesn't have a nice GUI, but from the point
>of view of someone who deploys lots of similar machines a GUI of any
>sort is a negative, and
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
On Sun, 2015-05-10 at 17:11 +0200, Vincent Bernat wrote:
> The disease is that actual servers running actual free software can
> break at each boot because we cannot have both a persistent naming
> scheme and use the eth* prefix is worse that the cure because old
> versions of Novell ZENworks may s
On Sun, 2015-05-10 at 23:57 +0200, Josselin Mouette wrote:
> Le vendredi 08 mai 2015 à 20:14 +0200, Marc Haber a écrit :
> > Do we have other network software other than ifupdown,
> > systemd-networkd and network-manager, the latter handling dynamic
> > names rather ungracefully.
>
> The NM config
Le vendredi 08 mai 2015 à 20:14 +0200, Marc Haber a écrit :
> Do we have other network software other than ifupdown,
> systemd-networkd and network-manager, the latter handling dynamic
> names rather ungracefully.
The NM configuration is based on MAC addresses and doesn’t care about
the interface
On Sun, 2015-05-10 at 22:23 +0200, Vincent Danjean wrote:
> Le 10/05/2015 16:24, Vincent Bernat a écrit :
> > Actually, when rebooting your (mission-critical) server, you can have a
> > race condition where "eth1" is not the interface that was "eth1" on the
> > previous boot and "rename5" is the in
Le 10/05/2015 16:24, Vincent Bernat a écrit :
> Actually, when rebooting your (mission-critical) server, you can have a
> race condition where "eth1" is not the interface that was "eth1" on the
> previous boot and "rename5" is the interface that should be
> "eth1". That's what needs to be fixed. Do
On Sun, May 10, 2015 at 07:09:41PM +0200, Marc Haber wrote:
On Sun, 10 May 2015 17:11:03 +0200, Vincent Bernat
wrote:
The disease is that actual servers running actual free software can
break at each boot because we cannot have both a persistent naming
scheme and use the eth* prefix is worse
J
On Sat, May 09, 2015 at 05:55:36PM -0700, Cameron Norman wrote:
> On Sat, May 9, 2015 at 2:36 PM, Josh Triplett wrote:
> > Marvin Renich wrote:
> >> * Martin Pitt [150509 05:27]:
> >> > TBH, hotpluggable USB network adapters which change all the time sound
> >> > like a corner case in a server wo
On Sun, 10 May 2015 17:11:03 +0200, Vincent Bernat
wrote:
>The disease is that actual servers running actual free software can
>break at each boot because we cannot have both a persistent naming
>scheme and use the eth* prefix is worse
Just for the record, an unexpected interface name change hasn
❦ 10 mai 2015 10:45 -0400, The Wanderer :
>> Do you speak about ifupdown? It's Debian only. eth* interfaces is
>> not *nix at all since all BSD are using per-driver naming
>> convention.
>
> Upon consideration, I suspect that I've been making - at least - the
> following three assumptions:
>
> *
On 05/10/2015 at 10:24 AM, Vincent Bernat wrote:
> ❦ 10 mai 2015 08:20 -0400, The Wanderer :
>
Were you actually using ifupdown to manage the varied set of
wireless networks? Because if not, then the name shouldn't
matter.
>>>
>>> Yes, I’m using ifupdown. Besides USB NICs don’
❦ 10 mai 2015 08:20 -0400, The Wanderer :
>>> Were you actually using ifupdown to manage the varied set of
>>> wireless networks? Because if not, then the name shouldn't
>>> matter.
>>
>> Yes, I’m using ifupdown. Besides USB NICs don’t have to be WiFi.
>
> Lots of people are, and it's inapprop
On 05/10/2015 at 07:36 AM, Stephan Seitz wrote:
> On Sat, May 09, 2015 at 02:36:30PM -0700, Josh Triplett wrote:
>
>> Why? What does a stable name matter in the case you mentioned?
>
> Because I don’t want to look up the interface name of the day when I
> use wireshark/tshark? Because I don’t w
On Sat, May 09, 2015 at 02:36:30PM -0700, Josh Triplett wrote:
Why? What does a stable name matter in the case you mentioned?
Because I don’t want to look up the interface name of the day when I use
wireshark/tshark? Because I don’t want to change my iptables scripts
which is working very we
On Sat, May 9, 2015 at 2:36 PM, Josh Triplett wrote:
> Marvin Renich wrote:
>> * Martin Pitt [150509 05:27]:
>> > TBH, hotpluggable USB network adapters which change all the time sound
>> > like a corner case in a server world where you have hand-written
>> > config files referring to interface n
* Josh Triplett [150509 17:37]:
> Marvin Renich wrote:
> > I disagree that stable interface names do not matter for USB adaptors
> > for consumer laptops. I have owned two laptops where the on-board WiFi
> > adaptor was too new to have reliable Linux drivers until 6-12 months
> > after I purchase
Marvin Renich wrote:
> * Martin Pitt [150509 05:27]:
> > TBH, hotpluggable USB network adapters which change all the time sound
> > like a corner case in a server world where you have hand-written
> > config files referring to interface names. They are of course common
> > on the client side, but
* Martin Pitt [150509 05:27]:
> TBH, hotpluggable USB network adapters which change all the time sound
> like a corner case in a server world where you have hand-written
> config files referring to interface names. They are of course common
> on the client side, but there stable interface names do
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, 08 May 2015 21:54:11 +0300, Timo Juhani Lindfors
wrote:
>Marc Haber writes:
>> Btw, why the is the only way to configure this the kernel
>> command line and no configuration inside /etc where one would expect
>> it?
>
>Maybe because udev is started from initramfs before the root filesyst
On Fri, 2015-05-08 at 12:41 +0200, Marc Haber wrote:
> On Fri, 8 May 2015 00:33:58 -0700, Josh Triplett
> wrote:
> >To help migrate existing systems, I'd suggest including a NEWS.Debian
> >file that explains the change, and recommends deleting
> >/etc/udev/rules.d/70-persistent-net.rules on system
❦ 8 mai 2015 23:03 +0200, Marc Haber :
>>There are much better alternatives for most common cases.
>
> For example being?
firewalld works nicely nowadays. You assign different level of security
to different networks. When I dock my laptop, network manager configures
the network interface and f
On Fri, 8 May 2015 13:33:06 -0700, j...@joshtriplett.org wrote:
>There are much better alternatives for most common cases.
For example being?
Greetings
Ma "iptables --table INPUT --interface eth+ --jump REJECT" rc
--
-- !! No courtesy copies, please !! -
M
On Fri, 8 May 2015 11:36:44 -0700, Josh Triplett
wrote:
>Also, what do you mean by NetworkManager handling dynamic names "ungracefully"?
I just remember having horrible trouble. Otherwise I would have filed
a bug report.
Greetings
Marc
--
-- !! No courtesy co
Marc Haber writes:
> Btw, why the is the only way to configure this the kernel
> command line and no configuration inside /etc where one would expect
> it?
Maybe because udev is started from initramfs before the root filesystem
has been mounted?
--
To UNSUBSCRIBE, email to debian-devel-requ..
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
Marc Haber wrote:
> On Fri, 8 May 2015 10:50:30 -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
> >> unsuitable behaviour with pluggable devices such
On Fri, 8 May 2015 10:50:30 -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
>> unsuitable behaviour with pluggable devices such as USB network
>> adapters. W
Am 08.05.2015 um 18:31 schrieb 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. When using ifnames, the interface name
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
> unsuitable behaviour with pluggable devices such as USB network
> adapters. When using ifnames, the interface name depends on the
> USB por
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
Tollef Fog Heen wrote:
> ]] Marc Haber
>
> > That would mean changing local code to _both_ handle en* and eth*,
> > which is (a) a surprise and (b) unsatisfying in _my_ personal opinion.
>
> By en*, you mean emN, enN, pXpY all, right?
Or more generally anything that enumerates as a network devic
On Fri, 08 May 2015 15:11:06 +0200, Tollef Fog Heen
wrote:
>]] Marc Haber
>
>> That would mean changing local code to _both_ handle en* and eth*,
>> which is (a) a surprise and (b) unsatisfying in _my_ personal opinion.
>
>By en*, you mean emN, enN, pXpY all, right?
yes.
Greetings
Marc
--
]] Marc Haber
> That would mean changing local code to _both_ handle en* and eth*,
> which is (a) a surprise and (b) unsatisfying in _my_ personal opinion.
By en*, you mean emN, enN, pXpY all, right?
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To U
On Fri, 8 May 2015 12:40:39 +0200, Martin Pitt
wrote:
>I don't
>know whether it's possible to change the name while the interface is
>up and in use.
It isn't.
Greetings
Marc
--
-- !! No courtesy copies, please !! -
Marc Haber | " Questions are t
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:
>To help migrate existing systems, I'd suggest including a NEWS.Debian
>file that explains the change, and recommends deleting
>/etc/udev/rules.d/70-persistent-net.rules on systems that don't depend
>on the exact names (for instance, systems
On Fri, 8 May 2015 00:28:44 -0700, Josh Triplett
wrote:
>Marc Haber wrote:
>>I have tried this just last week and have found it kind of
>>unsatisfactory that it doesn't work in virtualized environments. For
>>example, in a KVM VM with virtio ethernet, the network devices still
>>end up in the syst
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,
Marc Haber wrote:
>On Fri, 8 May 2015 07:59:31 +0200, Martin Pitt
>wrote:
>>Details about [ifnames]
>>---
>>This is a generic solution which extends the [biosdevname] idea and
>>thus applies to all practical cases and all architectures. It doesn't
>>need any persistant state (i
On Fri, 8 May 2015 07:59:31 +0200, Martin Pitt
wrote:
>Details about [ifnames]
>---
>This is a generic solution which extends the [biosdevname] idea and
>thus applies to all practical cases and all architectures. It doesn't
>need any persistant state (i. e. dynamic /etc/udev/ru
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 Debianists,
Quick intro to the problem: The kernel generally detects network
interfaces ("eth0", "wlan1", etc.) in an unpredictable and often
unstable order. But in order to refer to a particular one in
/etc/network/interfaces, firewall configs etc. you need to use a
stable name.
The genera
85 matches
Mail list logo
