Issues with dracut and network device naming

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.

Quoted 5 lines

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

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Harald Hoyer wrote:
[snip]

Quoted 6 lines

Quoted 5 lines

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.

Quoted 1 line

yes, sane solution .. +1

Yes, +1 as well. I'd vote for not doing this inside the ip= parameter, but use something like ifname=iface:mac.

Hi,

Quoted 8 lines · Seewer Philippe

Harald Hoyer wrote:
[snip]

Quoted 5 lines

Quoted 5 lines

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.

Quoted 4 lines

Quoted 1 line

yes, sane solution .. +1

Yes, +1 as well. I'd vote for not doing this inside the ip= parameter, but use something like ifname=iface:mac.

Hmm, I'm not so sure about that, it sure would be easier for the genrules script to have all the info in one place, instead of having to piece bits together.

Quoted 11 lines · Hans de Goede

Hi,

Quoted 9 lines · Seewer Philippe

Harald Hoyer wrote:
[snip]

Quoted 6 lines

Quoted 5 lines

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

Quoted 6 lines

Quoted 3 lines

Yes, +1 as well. I'd vote for not doing this inside the ip= parameter, but use something like ifname=iface:mac.

Hmm, I'm not so sure about that, it sure would be easier for the genrules script to have all the info in one place, instead of having to piece bits together.

Yes. But I think from a user's point of view, the ip= argument is already overloaded. ifname= (or whatever) would be much clearer and easier.

Regards,
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 16 lines · Hans de Goede

Hi,

Quoted 12 lines · Seewer Philippe

Harald Hoyer wrote:
[snip]

Quoted 6 lines

Quoted 5 lines

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

Yes, +1 as well. I'd vote for not doing this inside the ip= parameter, but use something like ifname=iface:mac.

Quoted 3 lines

Hmm, I'm not so sure about that, it sure would be easier for the genrules script to have all the info in one place, instead of having to piece bits together.

Yes. But I think from a user's point of view, the ip= argument is already overloaded. ifname= (or whatever) would be much clearer and easier.

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.

Quoted 4 lines · Hans de Goede

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.

It's worth talking to Prarit about this stuff because he's looking into persistent network device naming issues in general. I'm sure you know, but there's a generic DMI extension that allows you to determine from the system what the PCI slot->device name mapping should be so that e.g. moving the disk from one system to another doesn't affect the naming.

Of course this only works on systems with the requisite SMBUS/DMI extension *but* it will (eventually) be a nice solution to the naming issues and worth working with him on if you're not already.

Hi all,
But in the future it could also be something like for example:
ifname=eth0:/sys/devices/bus/pci/00:00:00:01.5

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

But in the future it could also be something like for example:
ifname=eth0:/sys/devices/bus/pci/00:00:00:01.5