Gerard Beekmans wrote: > Aren't we back to square one after you enable more drivers. Then after > the first reboot of "kernel with additional drivers" you have to go > through the discovery again of which card has which name assigned.
No, we aren't. 1) First boot, with only an Intel card recognized: it gets eth0, and an entry is written to the persistent rules database so that it remains at eth0 even when other cards are added to the system. 2) Second boot, with both Intel and Realtek cards. Due to the old entry in the database, the Intel card remains at eth0, while the Realtek card gets eth1. However, at USU, there were the following multi-card situations: 1) ums.usu.ru, before the old server died: two onboard Intel cards, both connected to different networks, and only one of them is public. 2) dsa.physics.usu.ru, before hardware upgrade: three Intel PCI cards, and only one of them is public. 3) dsa.physics.usu.ru, after the upgrade: one PCI Intel card facing the outside world, two D-Link gigabit PCI cards looking into the internal nets. 4) internal SAMBA server, after the upgrade: one old unused Intel card (combined with a video card, so can't remove), and a D-Link gigabit PCI card. So the scenario with blacklisting (or not building) some drivers would have worked only with 50% of cases. > Because the scenarios are so varied this would take up an entire chapter > in the book just to cover them all in a readable manner. Putting that > information in an appendix would help to maintain the flow of the book > without too many "if then else" scenarios. For those cases, put a note > in chapter 7's network config to skip ahead to Appendix X and read up on > what can be done and if a scenario matches the builder's. The scenarios are varied, but some "default" suitable for most cases has to be in the book. Some options for this default are: 1) always reboot before configuring the network (any number of cards), see the hint if building remotely; 2) the book assumes that you have only one network card and configures only eth0, see the hint if you need something beyond this simple case; 3) always write udev rules by hand--the idea is simple! 4) your own variant. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
