Re: Issues with dracut and network device naming

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux