[LFS Trac] #2057: Udev-122

Bryan Kadzban bryan at kadzban.is-a-geek.net
Thu May 22 15:39:14 PDT 2008


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

Alexander E. Patrakov wrote:
> Gerard Beekmans wrote:
> 
>> Rather than trying to fix udev, and it sounds like there isn't a 
>> solution that isn't hackish and has a risk of not working any day 
>> now with new releases. How about we fix our network setup.
> 
> Yes, this is possible. However, this requires dropping udev and 
> moving to a static /etc/sysconfig/modules file.

I'm pretty sure that dropping udev and doing everything statically does
not fix the problem, though; I believe it actually makes it worse.

Yes, using a static /etc/sysconfig/modules fixes the issue if you have a
single device using each driver (e.g. the book's example one-Intel,
one-Realtek system), *and* if all drivers (except the last) have been
written to register their net-device before modprobe returns.  (USB NICs
could fail here.)  But it doesn't help if you have multiple devices all
using the same driver; I believe that assignment is still random.  Or at
least, I believe that it isn't guaranteed to remain stable.

I think you already know this, but for others: The bottom-level problem
is that with recent kernels, on any given boot, network interface names
can be assigned in any order (or equivalently, the order that interface
names are assigned is not guaranteed to be stable).  Because of that
instability, udev provides a method to assign persistent names; once you
use that, the only problem remaining is how the system chooses which
name to use the first time around.  That's what we're trying to do in
section 7.13.1: get the system to decide on a name that will stay, and
one which the user also knows, so the user can configure each interface.

(In short, udev does not create the random interface order issue; it
fixes it for every boot after the first.)

Always using DHCP on all interfaces is one option, to be sure (assuming
DHCP is available on all networks, of course).  Trying to ping the
default gateway is another.  Neither is perfect (but OTOH, neither are
many of the different methods for using udev in section 7.13.1).

Figuring out some other way to describe the NIC in the network config
files would be another way (then the files could either consult the
just-written udev rules files, or they could look at sysfs, or they
could even perhaps write rules on their own like I *think* Fedora does,
though I wouldn't want to do that).  Anyway, that way you don't have a
config directory for eth0; you have a config directory for the card with
MAC aa:bb:cc:dd:ee:ff, or the card with physical-path <whatever>.

(What I'd like to do is get udev-122 into SVN along with the "udevadm
test" option, for now.  Any fixing of the network configuration can, of
course, change around section 7.13.1 later.  :-) )
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFINfYQS5vET1Wea5wRAyDpAJ9AbWdVyQP62zUPYgTXaR8NSn+WggCghRZm
5WhC1mHT2khy73X9r0P1pyU=
=4r6B
-----END PGP SIGNATURE-----




More information about the lfs-dev mailing list