They are stable as long as the kernel and the hardware do not change too
much; e.g. enabling the "other" graphics card in a hybrid setup
sometimes adds a PCIe bus, so all names shift around.
Or adding something like a firewire card which happens to be based on a
PCIe to PCI bridge chip would
Hi,
Am 10.09.2013 02:06, schrieb Patrick Lauer:
> On 09/10/2013 02:50 AM, Lennart Poettering wrote:
>> See
>> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
>>
>> The resulting names are somtimes a bit ugly, but predictable and stable,
>> and do not change on e
Btw, we didn't remove support for the new predictable network interface
naming scheme.
It's explicitly opt-in atm and you can use it by setting the
net.ifnames=1 kernel command line parameter [1].
Existing NAMEs set via /etc/udev/rules.d/70-persistent-net.rules still
take precedence, so you will h
Uoti Urpala writes:
> Russ Allbery wrote:
>>Kay Sievers writes:
>> > Hmm, why would upgrades break?
>>
>> > The old file would still be there, rename the devices (if you keep the
>> > patch to swap names, which upstream does not support any more), and take
>> > precedence over tht new names; the
Am 10.09.2013 01:28, schrieb Uoti Urpala:
> Russ Allbery wrote:
>> Kay Sievers writes:
>>> Hmm, why would upgrades break?
>>
>>> The old file would still be there, rename the devices (if you keep the
>>> patch to swap names, which upstream does not support any more), and take
>>> precedence over t
On 09/10/2013 02:50 AM, Lennart Poettering wrote:
> On Mon, 26.08.13 01:22, Thomas Goirand (z...@debian.org) wrote:
>
>>
>> On 08/24/2013 03:53 PM, Ben Hutchings wrote:
>>> There is a very clear standard that distinguishes globally and locally
>>> administered addresses.
>>>
>>> While you would po
Russ Allbery wrote:
>Kay Sievers writes:
> > Hmm, why would upgrades break?
>
> > The old file would still be there, rename the devices (if you keep the
> > patch to swap names, which upstream does not support any more), and take
> > precedence over tht new names; the old rules file would just no
Am 10.09.2013 00:05, schrieb Kay Sievers:
> On Tue, Sep 10, 2013 at 12:00 AM, Michael Biebl wrote:
>> Am 09.09.2013 23:53, schrieb Kay Sievers:
>>> Hmm, why would upgrades break?
>>
>> See [1], there are several cases where 75-persistent-net-generator.rules
>> doesn't generate a persistent name (m
Kay Sievers writes:
> On Mon, Sep 9, 2013 at 11:48 PM, Michael Biebl wrote:
>> We (Debian pkg-systemd team) decided to keep the old persistent naming
>> scheme "as default" for now, for the simple reason, that we didn't want
>> to break upgrades. It just didn't seem possible to detect every case
On Tue, Sep 10, 2013 at 12:00 AM, Michael Biebl wrote:
> Am 09.09.2013 23:53, schrieb Kay Sievers:
>> Hmm, why would upgrades break?
>
> See [1], there are several cases where 75-persistent-net-generator.rules
> doesn't generate a persistent name (mostly VM related). In those cases,
> you would ty
On Mon, Sep 09, 2013 at 08:50:48PM +0200, Lennart Poettering wrote:
[...]
> As a side note, also note that the MAC address range definitions are all
> blurred these days, MAC addresses are reused by manufacturers and most
> parsable meaning of MAC addresses has been removed (simply because the
> na
Hi Kay,
Am 09.09.2013 23:53, schrieb Kay Sievers:
> Hmm, why would upgrades break?
See [1], there are several cases where 75-persistent-net-generator.rules
doesn't generate a persistent name (mostly VM related). In those cases,
you would typically use eth0 in your /etc/network/interface etc.
On u
Hi Kay,
Am 09.09.2013 23:53, schrieb Kay Sievers:
> Hmm, why would upgrades break?
See [1], there are several cases where 75-persistent-net-generator.rules
doesn't generate a persistent name (mostly VM related). In those cases,
you would typically use eth0 in your /etc/network/interface etc.
On u
On Mon, Sep 9, 2013 at 11:26 PM, Ben Hutchings wrote:
> On Mon, Sep 09, 2013 at 08:50:48PM +0200, Lennart Poettering wrote:
> [...]
>> As a side note, also note that the MAC address range definitions are all
>> blurred these days, MAC addresses are reused by manufacturers and most
>> parsable mean
On Mon, Sep 9, 2013 at 11:48 PM, Michael Biebl wrote:
> Am 09.09.2013 20:50, schrieb Lennart Poettering:
>> It's now a Debianism to stick to the persistant names, all support for
>> it has been removed upstream. From upstream we hope DEbian eventually
>> drops support for the old persistant names
Hi Lennart,
Am 09.09.2013 20:50, schrieb Lennart Poettering:
> It's now a Debianism to stick to the persistant names, all support for
> it has been removed upstream. From upstream we hope DEbian eventually
> drops support for the old persistant names too.
We (Debian pkg-systemd team) decided to k
On Mon, 26.08.13 01:22, Thomas Goirand (z...@debian.org) wrote:
>
> On 08/24/2013 03:53 PM, Ben Hutchings wrote:
> > There is a very clear standard that distinguishes globally and locally
> > administered addresses.
> >
> > While you would possibly to buy your own OUI and make global assignments
Ben Hutchings wrote:
> But you don't actually want that behaviour. You cannot assume anything
> about the order in which net devices are created and therefore you still
> need rules for persistent names unless your machines have only one
> Ethernet(-like) interface (the usual VM case).
>
> You'll
On Mon, 2013-08-26 at 01:22 +0200, Thomas Goirand wrote:
> On 08/24/2013 03:53 PM, Ben Hutchings wrote:
> > There is a very clear standard that distinguishes globally and locally
> > administered addresses.
> >
> > While you would possibly to buy your own OUI and make global assignments
> > to you
On 08/24/2013 03:53 PM, Ben Hutchings wrote:
> There is a very clear standard that distinguishes globally and locally
> administered addresses.
>
> While you would possibly to buy your own OUI and make global assignments
> to your VMs, I seriously doubt you are doing that. Don't steal address
> s
On Sat, 2013-08-24 at 12:34 +0200, Thomas Goirand wrote:
> On 08/22/2013 03:12 AM, Peter Samuelson wrote:
> >
> > [Thomas Goirand]
> >> Oh ok. Not useful at all if you ask me. Why? Because sometimes, you
> >> can't change the MAC address. For example, if you use the OpenStack
> >> bare metal drive
On 08/22/2013 03:12 AM, Peter Samuelson wrote:
>
> [Thomas Goirand]
>> Oh ok. Not useful at all if you ask me. Why? Because sometimes, you
>> can't change the MAC address. For example, if you use the OpenStack
>> bare metal driver, then you continue to use virtual machine images,
>> though they wi
Michael Biebl writes:
> The persistent network interface naming rules are already skipped if
> udev is run within a virtual machine.
Which made me look closer at
/lib/udev/rules.d/75-persistent-net-generator.rules
I find it a bit strange that it has lots of logic involving different
OUIs, but
On Tue, Aug 20, 2013 at 09:58:43PM +0200, Thomas Goirand wrote:
> I'd be happy to find a correct and clean way to do this, because I also
> need to do it, and it seems to be a fairly common use case. I currently
> only delete the 75-persistent-net-generator.rules file (which I know is
> the wrong
I think I gonna simply skip the udev rules overriding, it will be up to the
user to do the cleaning if he wants to do cloning etc... as done in
cloud-init package, waiting for easier udev management from package side.
Thanks to all for your advises.
quoting previous...
--
>
> gpg key id: 4096R
[Thomas Goirand]
> Oh ok. Not useful at all if you ask me. Why? Because sometimes, you
> can't change the MAC address. For example, if you use the OpenStack
> bare metal driver, then you continue to use virtual machine images,
> though they will be used on a real hardware where you can't change
>
2013/8/21 Peter Palfrader
> On Tue, 20 Aug 2013, Thomas Goirand wrote:
>
> > I'd be happy to find a correct and clean way to do this, because I also
> > need to do it, and it seems to be a fairly common use case. I currently
> > only delete the 75-persistent-net-generator.rules file (which I know
On Tue, 20 Aug 2013, Thomas Goirand wrote:
> I'd be happy to find a correct and clean way to do this, because I also
> need to do it, and it seems to be a fairly common use case. I currently
> only delete the 75-persistent-net-generator.rules file (which I know is
> the wrong way to do it as it wo
On 08/20/2013 11:44 PM, Vincent Bernat wrote:
> ❦ 20 août 2013 22:00 CEST, Thomas Goirand :
>
>>> I did not know that udev skipped (at least) persistent-net in virtual
>>> machines so I did not try without those replacement rules (how does it
>>> know it is a virtual machine?).
>>
>> Oh, missed
❦ 20 août 2013 22:00 CEST, Thomas Goirand :
>> I did not know that udev skipped (at least) persistent-net in virtual
>> machines so I did not try without those replacement rules (how does it
>> know it is a virtual machine?).
>
> Oh, missed that part! I also would be happy to know how it does it
Ccing the list
-- Message transféré --
De : "olivier sallou"
Date : 20 août 2013 22:27
Objet : Re: overriding udev rules
À : "Thomas Goirand"
Le 20 août 2013 22:18, "Thomas Goirand" a écrit :
>
> On 08/20/2013 07:02 PM, olivier sallou
On 08/20/2013 07:02 PM, olivier sallou wrote:
> I did not know that udev skipped (at least) persistent-net in virtual
> machines so I did not try without those replacement rules (how does it
> know it is a virtual machine?).
Oh, missed that part! I also would be happy to know how it does it.
Thom
On 08/20/2013 07:02 PM, olivier sallou wrote:
> ok,
> I am packaging a package for OpenNebula that is to be installed on
> virtual machine images.
> It does many setup at startup.
> Among other things, in upstream packages, it replaces 2 udev rules:
> 75-cd-aliases-generator.rules and 75-persistent
2013/8/20 olivier sallou
>
>
>
> 2013/8/20 Michael Biebl
>
>> Am 20.08.2013 10:39, schrieb olivier sallou:
>> > hi,
>> > I need for a package to override some udev standard rules.
>> >
>> > If I put an identical rule name in /etc/udev/rules.d, I know it
>> overrides
>> > the one in /lib/udev/rul
2013/8/20 Michael Biebl
> Am 20.08.2013 10:39, schrieb olivier sallou:
> > hi,
> > I need for a package to override some udev standard rules.
> >
> > If I put an identical rule name in /etc/udev/rules.d, I know it overrides
> > the one in /lib/udev/rules.d
> >
> >
> > However, lintian raises an e
> olivier sallou writes:
> > hi,
> > I need for a package to override some udev standard rules.
> >
> > If I put an identical rule name in /etc/udev/rules.d, I know it overrides
> > the one in /lib/udev/rules.d
> >
> >
> > However, lintian raises an error if I put an udev rule in /etc instead of
>
On Aug 20, olivier sallou wrote:
> This particular package is for use in virtual machines creation where
> package removes default network persistence.
Please explain what you are actually trying to achieve.
> Is there an other way to override udev rules in package or should I simply
> override
On Tue, Aug 20, 2013 at 10:39:13AM +0200, olivier sallou wrote:
> I need for a package to override some udev standard rules.
Well. This would be not suitable for a package in Debian itself.
> However, lintian raises an error if I put an udev rule in /etc instead of
> /lib.
lintian is moot for pr
Am 20.08.2013 10:39, schrieb olivier sallou:
> hi,
> I need for a package to override some udev standard rules.
>
> If I put an identical rule name in /etc/udev/rules.d, I know it overrides
> the one in /lib/udev/rules.d
>
>
> However, lintian raises an error if I put an udev rule in /etc instea
On Tue, Aug 20, 2013 at 10:39:13AM +0200, olivier sallou wrote:
> hi,
> I need for a package to override some udev standard rules.
>
> If I put an identical rule name in /etc/udev/rules.d, I know it overrides
> the one in /lib/udev/rules.d
> [...]
> Is there an other way to override udev rules in
olivier sallou writes:
> hi,
> I need for a package to override some udev standard rules.
>
> If I put an identical rule name in /etc/udev/rules.d, I know it overrides
> the one in /lib/udev/rules.d
>
>
> However, lintian raises an error if I put an udev rule in /etc instead of
> /lib.
> And if I
hi,
I need for a package to override some udev standard rules.
If I put an identical rule name in /etc/udev/rules.d, I know it overrides
the one in /lib/udev/rules.d
However, lintian raises an error if I put an udev rule in /etc instead of
/lib.
And if I try to put the file in /lib, it fails at
42 matches
Mail list logo
