-----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----- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
