[LFS Trac] #2057: Udev-122

Bruce Dubbs bruce.dubbs at gmail.com
Wed May 21 22:57:50 PDT 2008

Gerard Beekmans wrote:

> Scenario 1: you have multiple network cards but only one card is plugged into
> an actual cable and thus has a link. That card, whichever it is, needs to be
> activated.
> Possible solution 1: install dhclient in LFS rather than BLFS. Configure 
> bootscripts to run dhclient on every interface. Only one interface will 
> receive an IP address from a router - ie an IP address that you need it to
> get for remote access.
> At this point you don't yet care if the kernel called that interface eth0,
> eth1, or something else. You can fix that after the 1st reboot if desired.

In the situation with a remote system, I don't think dhcp is ever an option.
You need to know what the IP address is to log in and you wouldn't know that for
sure before a reboot.  Catch 22.

> Possible solution 2: If static IP is needed, configure every network 
> interface for the same IP address.
> Enhance the network boot scripts to first check for a link before assigning
> the IP address.

Would this work?  You would have to know the ip address of the gateway attached 
to the network card.  If two cards have the same ip address, will the system try 
to sent outbound packets via both cards?

If the cards required different drivers, you could build the kernel with only 
one driver and thus ensure only eth0.

> There are a lot more scenarios that come to mind having worked in data 
> centers and setup ISP networks. You're going to find situations where you
> have multiple network cards all connected to the public internet via load
> balancing setups. Or just redundancy then you have your lovely BGP setups.
> How many do we need to support though for that 1st reboot (after which things
> will change anyways as your config settles down).

The question is whether we want to tackle this in the book or not.  It does seem 
to be a bucket of worms and so specialized that it really doesn't belong in the 

   -- Bruce

More information about the lfs-dev mailing list