29.05.2016 19:55, Michael Biebl пишет:
> 2016-05-29 18:28 GMT+02:00 Lennart Poettering :
>> On Sat, 28.05.16 21:38, Martin Pitt (martin.p...@ubuntu.com) wrote:
>>
>>> Chris Friesen [2016-05-27 9:14 -0600]:
The reason why I'm poking at this is that the old scheme worked "good
enough" for
2016-05-29 18:28 GMT+02:00 Lennart Poettering :
> On Sat, 28.05.16 21:38, Martin Pitt (martin.p...@ubuntu.com) wrote:
>
>> Chris Friesen [2016-05-27 9:14 -0600]:
>> > The reason why I'm poking at this is that the old scheme worked "good
>> > enough" for us for several years. Now of course the new
On Sat, 28.05.16 21:38, Martin Pitt (martin.p...@ubuntu.com) wrote:
> Chris Friesen [2016-05-27 9:14 -0600]:
> > The reason why I'm poking at this is that the old scheme worked "good
> > enough" for us for several years. Now of course the new scheme is better,
> > but it breaks backwards compati
Chris Friesen [2016-05-27 9:14 -0600]:
> The reason why I'm poking at this is that the old scheme worked "good
> enough" for us for several years. Now of course the new scheme is better,
> but it breaks backwards compatibility. This makes it difficult to
> automatically upgrade an existing syste
On Fri, 27.05.16 09:14, Chris Friesen (cbf...@mail.usask.ca) wrote:
> >Well, udev just modprobes the driver. The driver then probes all
> >devices and that happens in any order it likes.
>
> Looking at the kernel code, the probing order for pci NICs for a given
> driver is pretty well determinist
On Fri, May 27, 2016 at 09:14:51AM -0600, Chris Friesen wrote:
> On 05/27/2016 08:36 AM, Lennart Poettering wrote:
> > On Thu, 26.05.16 12:28, Chris Friesen (cbf...@mail.usask.ca) wrote:
> >
> > > So I've been playing with this a bit, but I've run into another snag. It
> > > seems that on initial
2016-05-27 17:51 GMT+02:00 Chris Friesen :
> The issue is not that the renaming fails (I actually modified the kernel to
> start at eth1000 so there is no possibility of collision).
>
> The problem is that the kernel-assigned "ethX" names are not deterministic.
> If I take two identical systems and
On 05/27/2016 09:43 AM, Michael Biebl wrote:
2016-05-27 17:14 GMT+02:00 Chris Friesen :
And the annoying thing is that if I turn off the new naming scheme there
seems to be less determinism than there used to be. I assume this is due to
the effort to extract more parallelism at boot, but it's c
2016-05-27 17:14 GMT+02:00 Chris Friesen :
> And the annoying thing is that if I turn off the new naming scheme there
> seems to be less determinism than there used to be. I assume this is due to
> the effort to extract more parallelism at boot, but it's causing me grief.
The old network interfac
On 05/27/2016 08:36 AM, Lennart Poettering wrote:
On Thu, 26.05.16 12:28, Chris Friesen (cbf...@mail.usask.ca) wrote:
So I've been playing with this a bit, but I've run into another snag. It
seems that on initial boot even with "net.ifnames=0" the ethernet interface
ordering isn't consistent.
On Thu, 26.05.16 12:28, Chris Friesen (cbf...@mail.usask.ca) wrote:
> So I've been playing with this a bit, but I've run into another snag. It
> seems that on initial boot even with "net.ifnames=0" the ethernet interface
> ordering isn't consistent.
>
> This means that two systems with identical
Am 26.05.2016 um 20:28 schrieb Chris Friesen:
So I've been playing with this a bit, but I've run into another snag.
It seems that on initial boot even with "net.ifnames=0" the ethernet
interface ordering isn't consistent.
This means that two systems with identical hardware can end up mapping
"
On 05/26/2016 01:59 PM, Greg KH wrote:
On Thu, May 26, 2016 at 01:49:07PM -0600, Chris Friesen wrote:
The thing that makes this all confusing/annoying is that when I was using a
homebrew distro with a 3.10 kernel and sysV init the interface ordering was
completely repeatable on identical hardw
On Thu, May 26, 2016 at 01:49:07PM -0600, Chris Friesen wrote:
> On 05/26/2016 12:41 PM, Martin Pitt wrote:
> > Chris Friesen [2016-05-26 12:28 -0600]:
> > > So I've been playing with this a bit, but I've run into another snag. It
> > > seems that on initial boot even with "net.ifnames=0" the ethe
On 05/26/2016 12:41 PM, Martin Pitt wrote:
Chris Friesen [2016-05-26 12:28 -0600]:
So I've been playing with this a bit, but I've run into another snag. It
seems that on initial boot even with "net.ifnames=0" the ethernet interface
ordering isn't consistent.
"even with" → "because of" :-)
Ho
Chris Friesen [2016-05-26 12:28 -0600]:
> So I've been playing with this a bit, but I've run into another snag. It
> seems that on initial boot even with "net.ifnames=0" the ethernet interface
> ordering isn't consistent.
"even with" → "because of" :-)
However, the ordering isn't really influenc
On 05/13/2016 08:54 AM, Chris Friesen wrote:
On 05/13/2016 01:23 AM, Lennart Poettering wrote:
On Thu, 12.05.16 12:34, Chris Friesen (cbf...@mail.usask.ca) wrote:
I booted the kernel with "net.ifnames=0", which worked to turn off the
location-based naming.
I then created a set of files, one p
On 05/13/2016 01:23 AM, Lennart Poettering wrote:
On Thu, 12.05.16 12:34, Chris Friesen (cbf...@mail.usask.ca) wrote:
I booted the kernel with "net.ifnames=0", which worked to turn off the
location-based naming.
I then created a set of files, one per eth device that match based on MAC:
[root@
On Thu, 12.05.16 12:34, Chris Friesen (cbf...@mail.usask.ca) wrote:
> I booted the kernel with "net.ifnames=0", which worked to turn off the
> location-based naming.
>
> I then created a set of files, one per eth device that match based on MAC:
>
> [root@compute-0 root]# cat /etc/systemd/network
12.05.2016 21:34, Chris Friesen пишет:
>
> So I guess the question is, how do I rename a device to a name that
> already exists? (Like supposing I want to swap the names of eth0 and
> eth1.)
>
You cannot (using current udev). This is exactly the code that was removed.
__
Am 12.05.2016 um 21:46 schrieb Chris Friesen:
So...anyone have any ideas why this isn't working? Is it because I'm
trying to use the "eth" namespace which could possibly collide with the
kernel naming?
likely yes
the config below has a reason while using network.service and classical
ifcfg
On 05/12/2016 01:27 PM, Chris Friesen wrote:
On 05/12/2016 12:50 PM, James Hogarth wrote:
>
> On 12 May 2016 18:28, "Chris Friesen" mailto:cbf...@mail.usask.ca>> wrote:
> >
> > Hi,
> >
> > Could someone point me to the commit that removed support for assigning
"ethX" names based on MAC add
On 05/12/2016 12:50 PM, James Hogarth wrote:
>
> On 12 May 2016 18:28, "Chris Friesen" mailto:cbf...@mail.usask.ca>> wrote:
> >
> > Hi,
> >
> > Could someone point me to the commit that removed support for assigning
"ethX" names based on MAC addresses?
> >
> > Alternately, can someone sug
>
> On 12 May 2016 18:28, "Chris Friesen" wrote:
> >
> > Hi,
> >
> > Could someone point me to the commit that removed support for assigning
"ethX" names based on MAC addresses?
> >
> > Alternately, can someone suggest a way to get equivalent behaviour (the
ability to set "ethX" names based on MAC
Am 12.05.2016 um 20:34 schrieb Chris Friesen:
So I guess the question is, how do I rename a device to a name that
already exists? (Like supposing I want to swap the names of eth0 and
eth1.)
you don't - if it works - be lucky - i am on some machines
but you can't do that relieable on many mac
Am 12.05.2016 um 19:52 schrieb Chris Friesen:
On 05/12/2016 11:35 AM, Reindl Harald wrote:
Am 12.05.2016 um 19:20 schrieb Chris Friesen:
Could someone point me to the commit that removed support for assigning
"ethX" names based on MAC addresses?
Alternately, can someone suggest a way to get
On 05/12/2016 11:36 AM, Lennart Poettering wrote:
On Thu, 12.05.16 11:20, Chris Friesen (cbf...@mail.usask.ca) wrote:
Hi,
Could someone point me to the commit that removed support for assigning
"ethX" names based on MAC addresses?
Alternately, can someone suggest a way to get equivalent behav
On Thu, 12.05.16 11:52, Chris Friesen (cbf...@mail.usask.ca) wrote:
> On 05/12/2016 11:35 AM, Reindl Harald wrote:
> >
> >
> >Am 12.05.2016 um 19:20 schrieb Chris Friesen:
> >>Could someone point me to the commit that removed support for assigning
> >>"ethX" names based on MAC addresses?
> >>
> >>
On 05/12/2016 11:35 AM, Reindl Harald wrote:
Am 12.05.2016 um 19:20 schrieb Chris Friesen:
Could someone point me to the commit that removed support for assigning
"ethX" names based on MAC addresses?
Alternately, can someone suggest a way to get equivalent behaviour (the
ability to set "ethX"
On Thu, 12.05.16 11:20, Chris Friesen (cbf...@mail.usask.ca) wrote:
> Hi,
>
> Could someone point me to the commit that removed support for assigning
> "ethX" names based on MAC addresses?
>
> Alternately, can someone suggest a way to get equivalent behaviour (the
> ability to set "ethX" names b
Am 12.05.2016 um 19:20 schrieb Chris Friesen:
Could someone point me to the commit that removed support for assigning
"ethX" names based on MAC addresses?
Alternately, can someone suggest a way to get equivalent behaviour (the
ability to set "ethX" names based on MAC address) using the current
Hi,
Could someone point me to the commit that removed support for assigning "ethX"
names based on MAC addresses?
Alternately, can someone suggest a way to get equivalent behaviour (the ability
to set "ethX" names based on MAC address) using the current infrastructure?
(Preferably as of RHEL
32 matches
Mail list logo