Issues with dracut and network device naming

Issues with dracut and network device naming

[Hans de Goede]

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.

Regards,

Hans

Re: Issues with dracut and network device naming

[Harald Hoyer]

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

Re: Issues with dracut and network device naming

[Seewer Philippe]

Harald Hoyer wrote:
[snip]
>> 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.

> 
> --
> To unsubscribe from this list: send the line "unsubscribe initramfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Issues with dracut and network device naming

[Hans de Goede]

Hi,

On 08/28/2009 02:45 PM, Seewer Philippe wrote:
>
>
> Harald Hoyer wrote:
> [snip]
>>> 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.
>

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.

Regards,

Hans

Re: Issues with dracut and network device naming

[Seewer Philippe]

Hans de Goede wrote:
> Hi,
> 
> On 08/28/2009 02:45 PM, Seewer Philippe wrote:
>>
>> Harald Hoyer wrote:
>> [snip]
>>>> 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.
>>
> 
> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Issues with dracut and network device naming

[Victor Lowther]

On Aug 28, 2009, at 10:25 AM, Seewer Philippe <philippe.seewer-omB+W0Dpw2o@public.gmane.org>  
wrote:

>
>
> Hans de Goede wrote:
>> Hi,
>> On 08/28/2009 02:45 PM, Seewer Philippe wrote:
>>>
>>> Harald Hoyer wrote:
>>> [snip]
>>>>> 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.
>>>
>> 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.
>

AOL. There is too much to remember for the ip= commandline param  
already.

> Regards,
> --
> To unsubscribe from this list: send the line "unsubscribe initramfs"  
> in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Issues with dracut and network device naming

[Hans de Goede]

Hi,

On 08/28/2009 05:25 PM, Seewer Philippe wrote:
>
>
> Hans de Goede wrote:
>> Hi,
>>
>> On 08/28/2009 02:45 PM, Seewer Philippe wrote:
>>>
>>> Harald Hoyer wrote:
>>> [snip]
>>>>> 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.
>>>
>>
>> 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.
>

See my relpy to Jon Masters mail about there in the future potentially being
other unique identifiers to persistenly name a NIC, given this I'm going to
implement a ifname=eth0:<unique-id> syntax, where for now the unique id will
be a mac, but this way we can easily use other unique-id strings in the future
(much more easily then when we put everything in the ip= syntax)

Regards,

Hans

Re: Issues with dracut and network device naming

[Jon Masters]

On Fri, 2009-08-28 at 14:14 +0200, Hans de Goede wrote:

> 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.

Jon.


--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Issues with dracut and network device naming

[Hans de Goede]

Hi all,

On 08/28/2009 04:36 PM, Jon Masters wrote:
> On Fri, 2009-08-28 at 14:14 +0200, Hans de Goede wrote:
>
>> 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.
>

Hmm, well I really want to have something in place soon, and currently
all Fedora persistent network device naming is done based on MAC.

But I would like to keep possibilities like this open for the future, so
I'll go ahead and implement Seewer's suggeston to use a separate cmdline
arg for this called ifname, for now we will then have / use:
ifname=eth0:aa:bb:cc:dd:ee:ff

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

Re: Issues with dracut and network device naming

[Victor Lowther]

On Mon, 2009-08-31 at 13:17 +0200, Hans de Goede wrote:
> 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

Hmmm... what guarantee is there that PCI device ordering is stable?

MAC addresses have the advantage of not being subject to change because
you flashed the system BIOS and things are enumerated in a different
order, or you decided to add a multifunction card that adds its own
brand-new set of PCI busses, and your dodgy BIOS decides to renumber
everything.

> Regards,
> 
> Hans
> --
> To unsubscribe from this list: send the line "unsubscribe initramfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Issues with dracut and network device naming

[Jon Masters]

On Mon, 2009-08-31 at 13:17 +0200, Hans de Goede wrote:

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

Right. Prarit and others are looking at how to expose the DMI-provided
slot information in e.g. sysfs - so then you'll have an entry that's a
symlink pointing to the device, setup according to the hardware vendor.

Jon.