Unless you can persuade the kernel developers to fix this then the
correct solution is to configure network interfaces as an effect of
hotplug events.
Eh.. excuse me, but did I get this right? Does this mean that there would
be no way of deconfiguring a network device which is not
On May 04, Juha Jäykkä [EMAIL PROTECTED] wrote:
Eh.. excuse me, but did I get this right? Does this mean that there would
be no way of deconfiguring a network device which is not hot-pluggable?
What I mean is, how do I generate a hotplug event for, e.g. a NIC that's
integrated to the
On Fri, Apr 21, 2006 at 02:16:07PM +0200, Marco d'Itri wrote:
Too bad that it is not what the kernel reports in the hotplug events and
that there are no symlinks in sysfs to access a kobject by its ifindex.
Sending a patch RFC to LKML would be the first step to improve this.
What stops udev
On Apr 25, Gabor Gombas [EMAIL PROTECTED] wrote:
What stops udev from looking up the index before invoking any of the
rules? That avoids the races and does not require kernel support at all.
Nothing, it's available as SYSFS{ifindex}.
What I do not understand is how you would use it.
--
ciao,
* Marco d'Itri:
On Apr 21, Florian Weimer [EMAIL PROTECTED] wrote:
KERNEL==*.*, GOTO=persistent_net_generator_end
No visible change.
There's an error message in the syslog:
Apr 21 10:05:30 l udevd-event[6705]: rename_net_if: error changing net
interface name eth0.1_ifrename to
On Apr 24, Florian Weimer [EMAIL PROTECTED] wrote:
It seems as if I've copied the line correctly, and I've also rebooted
the machine. I don't know why udev still wants to touch the
interface.
Because it has the same MAC address and no obvious sysfs attribute which
distinguishes it, so the
* Marco d'Itri:
On Apr 21, Guus Sliepen [EMAIL PROTECTED] wrote:
I'm sure there are people who use both ifrename and udev, and if udev
Which part of ifrename does not work with udev you did not understand?
Certainly nameif works with udev. Why should I care about missed
events for my
* Adam Borowski:
Idea: if /etc/iftab is present on upgrade, you can consume it,
producing relevant rules in that place (and displaying a message to
the admin).
There's also /etc/mactab, which is processed by nameif (from the
net-tools package). Ideally, this one should be processed, too.
* Marco d'Itri:
On Apr 20, Florian Weimer [EMAIL PROTECTED] wrote:
This looks like a bug in udev. It should not try to identify devices
based on names a user can and will change.
I think I missed which alternative design you are proposing.
I'm not familiar with udev, sorry.
This change
On Apr 21, Florian Weimer [EMAIL PROTECTED] wrote:
This change also broke the vlan package, which hasn't got to do much
with interface renaming (from a user perspective). New VLAN
interfaces are called eth0.1_ifrename instead of eth0.1.
Interesting, I think this happens because eth0 and
* Marco d'Itri:
On Apr 21, Florian Weimer [EMAIL PROTECTED] wrote:
This change also broke the vlan package, which hasn't got to do much
with interface renaming (from a user perspective). New VLAN
interfaces are called eth0.1_ifrename instead of eth0.1.
Interesting, I think this happens
On Apr 20, Adam Borowski [EMAIL PROTECTED] wrote:
Idea: if /etc/iftab is present on upgrade, you can consume it, producing
relevant rules in that place (and displaying a message to the admin).
An even better idea is, on the upgrade introducing persistent interface
names, to write rules which
On Apr 21, Florian Weimer [EMAIL PROTECTED] wrote:
KERNEL==*.*, GOTO=persistent_net_generator_end
No visible change.
There's an error message in the syslog:
Apr 21 10:05:30 l udevd-event[6705]: rename_net_if: error changing net
interface name eth0.1_ifrename to eth0: timeout
I think
On Fri, Apr 21, 2006 at 10:19:46AM +0200, Marco d'Itri wrote:
On Apr 20, Adam Borowski [EMAIL PROTECTED] wrote:
Idea: if /etc/iftab is present on upgrade, you can consume it, producing
relevant rules in that place (and displaying a message to the admin).
An even better idea is, on the
On Apr 21, Steve Langasek [EMAIL PROTECTED] wrote:
This was actually why I was asking. :) Does d-i really need to do anything
here, or can it simply depend on the udev postinst to take care of it all in
the chrooted target?
No, currently postinst when run in a chroot does as little as
On Fri, Apr 21, 2006 at 11:47:45AM +0200, Marco d'Itri wrote:
On Apr 21, Steve Langasek [EMAIL PROTECTED] wrote:
An even better idea is, on the upgrade introducing persistent interface
names, to write rules which reflect the current names no matter what
configured them.
And also, I
On Apr 21, Steve Langasek [EMAIL PROTECTED] wrote:
An even better idea is, on the upgrade introducing persistent interface
names, to write rules which reflect the current names no matter what
configured them.
And also, I hope, on initial install of udev?
Yes, and in d-i too.
--
ciao,
On Apr 21, Gabor Gombas [EMAIL PROTECTED] wrote:
Since there is a 1-1 connection between the interface index and the
in-kernel data structure, it is the ideal (and only) identifier udev
should use.
Too bad that it is not what the kernel reports in the hotplug events and
that there are no
On Thu, Apr 20, 2006 at 09:23:00PM +0200, Marco d'Itri wrote:
This looks like a bug in udev. It should not try to identify devices
based on names a user can and will change.
I think I missed which alternative design you are proposing.
AFAIK the only correct way to identify a network
On 04/21/06 10:19:46AM +0200, Marco d'Itri wrote:
On Apr 20, Adam Borowski [EMAIL PROTECTED] wrote:
Idea: if /etc/iftab is present on upgrade, you can consume it, producing
relevant rules in that place (and displaying a message to the admin).
An even better idea is, on the upgrade
On Apr 21, Jim Crilly [EMAIL PROTECTED] wrote:
An even better idea is, on the upgrade introducing persistent interface
names, to write rules which reflect the current names no matter what
configured them.
But won't that miss any devices that aren't in the system right at that
moment, such
On Thu, Apr 20, 2006 at 01:43:07AM +0200, Marco d'Itri wrote:
Besides the fact that ifrename is more of a hack, now that udev enables
persistent naming of interfaces (z25_persistent-net.rules) udev should
conflict with ifrename. Otherwise the user could get unexpected results
if
On Apr 21, Guus Sliepen [EMAIL PROTECTED] wrote:
I'm sure there are people who use both ifrename and udev, and if udev
Which part of ifrename does not work with udev you did not understand?
--
ciao,
Marco
signature.asc
Description: Digital signature
On Thu, Apr 20, 2006 at 01:43:07AM +0200, Marco d'Itri [EMAIL PROTECTED]
wrote:
If you have not noticed yet, the latest udev release by default
automatically generates rules to have persistent names for network
interfaces.
I am inclined to agree with the bug reporter, but I want to double
On Fri, Apr 21, 2006 at 10:32:21PM +0200, Marco d'Itri wrote:
I'm sure there are people who use both ifrename and udev, and if udev
Which part of ifrename does not work with udev you did not understand?
The part where both work fine simultaneously on my own machines.
--
Met vriendelijke
On Fri, Apr 21, 2006 at 10:32:21PM +0200, Marco d'Itri wrote:
On Apr 21, Guus Sliepen [EMAIL PROTECTED] wrote:
I'm sure there are people who use both ifrename and udev, and if udev
Which part of ifrename does not work with udev you did not understand?
Which part of let the user shoot his
On Thu, 20 Apr 2006, Peter Palfrader wrote:
I am inclined to agree with the bug reporter, but I want to double check
and ask if anybody has other arguments.
I use ifrename to give useful names to interfaces and just because udev
may be able to do this now as well does not mean they should
On Apr 20, Peter Palfrader [EMAIL PROTECTED] wrote:
I use ifrename to give useful names to interfaces and just because udev
may be able to do this now as well does not mean they should conflict.
No, ifrename cannot be used with udev because it cannot know that the
name of an interface has
On Thu, Apr 20, 2006 at 09:10:18AM +0200, Marco d'Itri wrote:
No, ifrename cannot be used with udev because it cannot know that the
name of an interface has changed and will not be able to correctly
deliver the hotplug events.
I do not understand how hotplug events enter the picture. I do not
On Apr 20, Gabor Gombas [EMAIL PROTECTED] wrote:
No, ifrename cannot be used with udev because it cannot know that the
name of an interface has changed and will not be able to correctly
deliver the hotplug events.
I do not understand how hotplug events enter the picture. I do not use
udev
On Thu, Apr 20, 2006 at 11:12:58AM +0200, Marco d'Itri wrote:
Result: programs run after ifrename (like ifupdown...) will get the old
name.
So what? The user deliberately asked for it. Also it seems easy to write
an udev rule to replace persistent-net-generator.rules using ifrename so
udev
On Apr 20, Gabor Gombas [EMAIL PROTECTED] wrote:
Result: programs run after ifrename (like ifupdown...) will get the old
name.
So what? The user deliberately asked for it. Also it seems easy to write
This does not make it less broken.
an udev rule to replace persistent-net-generator.rules
On Thu, 20 Apr 2006, Gabor Gombas wrote:
On Thu, Apr 20, 2006 at 11:12:58AM +0200, Marco d'Itri wrote:
Result: programs run after ifrename (like ifupdown...) will get the old
name.
So what? The user deliberately asked for it. Also it seems easy to write
an udev rule to replace
On Thu, Apr 20, 2006 at 01:52:14PM +0200, Marco d'Itri wrote:
On Apr 20, Gabor Gombas [EMAIL PROTECTED] wrote:
Result: programs run after ifrename (like ifupdown...) will get the old
name.
So what? The user deliberately asked for it. Also it seems easy to write
This does not make it
On Apr 20, Wouter Verhelst [EMAIL PROTECTED] wrote:
will be closed with (at most) a pointer to that file; but I don't see
why you shoul _forbid_ people to use it after being duly warned.
Because *it does not work*.
I am not sure how I could express this concept in other ways.
--
ciao,
Marco
On Thu, Apr 20, 2006 at 03:01:19PM +0200, Marco d'Itri wrote:
On Apr 20, Wouter Verhelst [EMAIL PROTECTED] wrote:
will be closed with (at most) a pointer to that file; but I don't see
why you shoul _forbid_ people to use it after being duly warned.
Because *it does not work*.
So? IMAO,
On Thu, Apr 20, 2006 at 01:52:14PM +0200, Marco d'Itri wrote:
This does not make it less broken.
Why? Care to point out just one single feature that is broken, provided
that the interface is _not_ configured to be automatically brought up in
/etc/network/interfaces?
But it's not.
That's
* Marco d'Itri:
udev receives the hotplug event for eth0
udev starts dispatching the event for eth0
udev runs ifrename which renames eth0 to eth1
udev cannot detect this and continues dispatching the event for eth0
This looks like a bug in udev. It should not try to identify devices
based
On Apr 20, Florian Weimer [EMAIL PROTECTED] wrote:
This looks like a bug in udev. It should not try to identify devices
based on names a user can and will change.
I think I missed which alternative design you are proposing.
--
ciao,
Marco
signature.asc
Description: Digital signature
Package: udev
Version: 0.090-1
Severity: normal
Besides the fact that ifrename is more of a hack, now that udev enables
persistent naming of interfaces (z25_persistent-net.rules) udev should
conflict with ifrename. Otherwise the user could get unexpected results
if /etc/iftab still exists and the
If you have not noticed yet, the latest udev release by default
automatically generates rules to have persistent names for network
interfaces.
I am inclined to agree with the bug reporter, but I want to double check
and ask if anybody has other arguments.
On Apr 20, Michael Biebl [EMAIL
On Thu, 20 Apr 2006, Marco d'Itri wrote:
On Apr 20, Michael Biebl [EMAIL PROTECTED] wrote:
Besides the fact that ifrename is more of a hack, now that udev enables
persistent naming of interfaces (z25_persistent-net.rules) udev should
conflict with ifrename. Otherwise the user could get
42 matches
Mail list logo
