problem description revised [was: Re: udev-110 ->111 changed behaviour for naming net-devices?]
bryan at kadzban.is-a-geek.net
Fri Jun 8 16:45:50 PDT 2007
-----BEGIN PGP SIGNED MESSAGE-----
Jens Stroebel wrote:
> Problems arise when card b is found first, because:
> card b becomes eth0
> our custom rule wants to assign card a -> eth0
> card b gets moved out of the way; because card a is still eth1, card
> b becomes eth1_rename.
> card a becomes eth0; but card b stays eth1_rename
> Shouldn't the final step (eth1_rename -> eth1) be done somehow by
Yes, it should be renamed back to eth1 once the old eth1 (card a) has
been named eth0. That is, unless the udevd timeout has already happened
- -- I'm not sure how long the timeout is, but I know there is one when
renaming NICs. I think it's somewhere on the order of a couple minutes.
When udevd tries to rename an interface, it does the rename ioctl once,
and if it gets a "name in use" error, it names it *_rename instead,
sleeps for a while, and tries again. But there's a maximum total amount
of time that it'll wait before just giving up.
But the card has to be renamed before this *_rename code comes into play
at all -- if you don't have any rule for card b, I don't see how it
could ever move from eth0 to either eth1 or eth1_rename. I can see udev
naming card a eth1_rename while waiting for card b (eth0) to be named
eth1, if there is no rule for card b. But not how you describe.
I'd still strongly recommend keeping a rule for card b though. If the
patched path_id works, that should be fine.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the lfs-dev