On 08/28/2009 02:14 PM, Hans de Goede wrote:
Hi all, When using iscsi for example, an interface name (usually eth#) is specified on the dracut cmdline, but if a machine has multiple nics the probe order done by dracut may very well differ as the one which was used during install when the dracut cmdline gets generated. For the fcoe support I've allowed specifying a mac address instead, however this has issues too. As now the udev run from rc.sysinit complains it cannot rename the interface to what the running system expects as the interface is busy (oops). So it looks like we need to somehow tell dracut to use the same mac <-> interface name mapping as during the running system. One way of doing this would be to have a configuration initrd with the persistent net rules. But I see multiple issues with this: 1) I'm not sure all bootloaders support loading multiple initrd's and I'm not sure dracut supports having files over multiple initrd's at the moment either 2) Merging the generic initrd and the config initrd, although it should be safe may turn out fragile 3) To me the biggest problem. Currently what dracut does is very transparent, if we know the cmdline and the hardware configuration / disk layouts, we should be able to predict what it is going to do Once we start hiding configration inside an image file, it becames less transparent 4) I don't know how well the persistent network device rules and our current generated during boot network device rules play together. The current generated rules do not seem to be ready for handling device name changes So I would like to propose another solution for this, allow specifying both an interface-name and a mac with ip=, and then have the dracut generated rules do the rename and init. This way problems 3) and 4) above are solved, and we can easily also write the mac address to grub.conf from anaconda when generating the ip= cmdline.
yes, sane solution .. +1 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list