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
Am 10.09.2013 01:28, schrieb Uoti Urpala:
Russ Allbery wrote:
Kay Sievers k...@vrfy.org 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
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Russ Allbery wrote:
Kay Sievers k...@vrfy.org 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
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
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 every VM
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
to
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
On Mon, Sep 9, 2013 at 11:48 PM, Michael Biebl bi...@debian.org 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
On Mon, Sep 9, 2013 at 11:26 PM, Ben Hutchings b...@decadent.org.uk 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
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
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
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
On Tue, Sep 10, 2013 at 12:00 AM, Michael Biebl bi...@debian.org 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,
Kay Sievers k...@vrfy.org writes:
On Mon, Sep 9, 2013 at 11:48 PM, Michael Biebl bi...@debian.org 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
Am 10.09.2013 00:05, schrieb Kay Sievers:
On Tue, Sep 10, 2013 at 12:00 AM, Michael Biebl bi...@debian.org 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
Russ Allbery wrote:
Kay Sievers k...@vrfy.org 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
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 possibly to buy
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 your VMs, I
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 need
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
space.
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 will be
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 driver, then you
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:
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 way
Michael Biebl bi...@debian.org 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
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 wont
2013/8/21 Peter Palfrader wea...@debian.org
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
[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
the
olivier sallou olivier.sal...@gmail.com 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 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
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 instead of
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
On Aug 20, olivier sallou olivier.sal...@gmail.com 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
olivier sallou olivier.sal...@gmail.com 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
2013/8/20 Michael Biebl bi...@debian.org
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
2013/8/20 olivier sallou olivier.sal...@gmail.com
2013/8/20 Michael Biebl bi...@debian.org
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
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
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.
Thomas
Ccing the list
-- Message transféré --
De : olivier sallou olivier.sal...@gmail.com
Date : 20 août 2013 22:27
Objet : Re: overriding udev rules
À : Thomas Goirand z...@debian.org
Le 20 août 2013 22:18, Thomas Goirand z...@debian.org a écrit :
On 08/20/2013 07:02 PM, olivier
❦ 20 août 2013 22:00 CEST, Thomas Goirand z...@debian.org :
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
On 08/20/2013 11:44 PM, Vincent Bernat wrote:
❦ 20 août 2013 22:00 CEST, Thomas Goirand z...@debian.org :
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
41 matches
Mail list logo
