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 mot
> 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 hot-plug
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.
--
cia
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 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, 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
* 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 m
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 sho
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 do
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 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 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 /e
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
> mom
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, 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 s
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 i
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 pos
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.
> > A
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.
--
c
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: ti
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 t
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 whic
* 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
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
* 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
* 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.
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 persistent-net-g
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
* 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
base
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?
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 ifr
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,
Marc
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 no
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
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 wi
Steve Langasek wrote:
> What's the sense of pointing this out when that field isn't implemented (or
> standardized)? Scott may object to how Conflicts: is used, but until Breaks
> exists and is available for use in Debian, it's the correct field to use.
Well, TBH, I'm still a bit confused about t
On Thu, Apr 20, 2006 at 09:01:40AM +, Reinhard Tartler wrote:
> Are there any file conflicts between udev and ifrename? If not, then
> according to the old dpkg maintainer, Scott Remnant, a Conflicts is not
> warranted. He mentioned this in the context of xscreensaver breaking
> gnomescreensave
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 u
On Thu, Apr 20, 2006 at 09:01:40AM +, Reinhard Tartler wrote:
> Marco d'Itri 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
Marco d'Itri 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 check
> and ask if anybody has other arguments.
>
> On Apr
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 n
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 ch
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 s
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 coul
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 PROTECTE
45 matches
Mail list logo
