problem description revised [was: Re: udev-110 ->111 changed behaviour for naming net-devices?]

Bryan Kadzban bryan at kadzban.is-a-geek.net
Fri Jun 8 16:45:50 PDT 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

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 
> something?

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

iD8DBQFGaeosS5vET1Wea5wRA25RAJ4yvvxbCCr9qbFoshmEZg75ImGXAQCg3QvM
UH9B326J1e0GuZwqcNDJh6g=
=FPuh
-----END PGP SIGNATURE-----



More information about the lfs-dev mailing list