I've just caught up on all the recent comments and I think I understand the root problem regarding multiple interfaces, the need to configure them before the first reboot so once you do reboot, you have a chance to remotely login.
After the 1st reboot it's not always known which of multiple cards ends up being eth0, eth1, etc seeing assignment is random by default unless we come up with a way to make it not random during our chroot stage. The comments further went on about certain kernel versions, having udev running on the host system, etc. That's problematic ground to walk on. We don't know if the host system has a new enough kernel. It may not even run udev. I hope I'm not repeating old ideas here. I didn't see these listed so here goes. 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. We can easily get a lot more advanced at this. This email may get long. Please bear with me. ----- 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. 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. Scenario 2: multiple cards are all plugged into networks. Likely different physical networks so "solution 2" above isn't going to work. Solution 1 from above may work but only if the location you are offers DHCP. Most data centers won't offer that so you're back to having to assign two static IP addresses to the proper interfaces. Mix them up, nothing works. It wouldn't be an unfair assumption to make that only one of your plugged in networks is the network to which you, the builder, is reachable (public Internet or a LAN). You know your current IP address. You know the IP address you need the server to have in order for you to connect to it. Have a bootscript assign the server's IP address to the first interface. Have the server try to ping you. If the ping fails, have the script move the IP address to the next interface until it's able to "find" your own computer. Then you login and clean up the networking files now that you know what is what. ----- I would wager a guess that "scenario 1" is the one we primarily will encounter. If not, would it be a fair assumption to make that if "scenario 2" is true, you request a person on-site to unplug the extra network cables so only one is plugged in through which you are building LFS. Then later on you can have the on-site techs plug your other cables back in. 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). -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
