From: Hans de Goede <hdegoede@redhat.com>
To: Seewer Philippe <philippe.seewer@bfh.ch>
Cc: initramfs <initramfs@vger.kernel.org>,
Discussion of Development and Customization of the Red Hat Linux
Installer <anaconda-devel-list@redhat.com>,
Harald Hoyer <harald@redhat.com>
Subject: Re: Issues with dracut and network device naming
Date: Mon, 31 Aug 2009 13:20:38 +0200 [thread overview]
Message-ID: <4A9BB206.4050609@redhat.com> (raw)
In-Reply-To: <4A97F6E6.4040206@bfh.ch>
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
next prev parent reply other threads:[~2009-08-31 11:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-28 12:14 Issues with dracut and network device naming Hans de Goede
2009-08-28 12:43 ` Harald Hoyer
[not found] ` <4A97D0F9.9020302-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-08-28 12:45 ` Seewer Philippe
2009-08-28 14:16 ` Hans de Goede
[not found] ` <4A97E6CA.2020200-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-08-28 15:25 ` Seewer Philippe
[not found] ` <4A97F6E6.4040206-omB+W0Dpw2o@public.gmane.org>
2009-08-28 20:55 ` Victor Lowther
2009-08-31 11:20 ` Hans de Goede [this message]
[not found] ` <4A97CA1A.5080606-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-08-28 14:36 ` Jon Masters
2009-08-31 11:17 ` Hans de Goede
[not found] ` <4A9BB155.8020106-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-08-31 13:32 ` Victor Lowther
2009-08-31 15:16 ` Jon Masters
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A9BB206.4050609@redhat.com \
--to=hdegoede@redhat.com \
--cc=anaconda-devel-list@redhat.com \
--cc=harald@redhat.com \
--cc=initramfs@vger.kernel.org \
--cc=philippe.seewer@bfh.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.