Reindl Harald schreef op 14-04-16 12:02:
>
>
> Am 14.04.2016 um 11:45 schrieb Jetchko Jekov:
>> On Thu, Apr 14, 2016 at 10:57 AM Reindl Harald > > can iterate over.
>> >
>> > $ ip -o a | awk '{print $2}' | uniq
>>
>> blub - gives a (incomplete) list of the current interfaces -
Am 14.04.2016 um 11:45 schrieb Jetchko Jekov:
On Thu, Apr 14, 2016 at 10:57 AM Reindl Harald can iterate over.
>
> $ ip -o a | awk '{print $2}' | uniq
blub - gives a (incomplete) list of the current interfaces - so what is
the advantage you wnated to demonstrate?
wrong
that
On Thu, Apr 14, 2016 at 10:57 AM Reindl Harald
wrote:
>
>
> Am 13.04.2016 um 18:51 schrieb Sam Tresler:
> > I didn't make it through the rest of your post, but thought I'd chime in
> > with `ifconfig` has been deprecated since 2009.
> >
> > 2009. I don't get deep into the distros, but I really wi
Am 13.04.2016 um 18:51 schrieb Sam Tresler:
I didn't make it through the rest of your post, but thought I'd chime in
with `ifconfig` has been deprecated since 2009.
2009. I don't get deep into the distros, but I really wish they'd stop
shipping it.
`man ip` should give you info on the right t
Sam Tresler schreef op 13-04-16 18:51:
>>Ifconfig does not show anything useful. lspci might provide something I
> can use to construct it, but I'm >not sure. "dmesg | grep enp3s0"
> confirms this, but I still need to manually construct the entire string.
>
> I didn't make it through the rest of y
>Ifconfig does not show anything useful. lspci might provide something
I can use to construct it, but I'm >not sure. "dmesg | grep enp3s0"
confirms this, but I still need to manually construct the entire string.
I didn't make it through the rest of your post, but thought I'd chime in
with `ifc
Greg KH schreef op 11-04-16 22:19:
>> My device is enp3s0, which implies 3rd bus number, which it indeed is:
>>
>> E: ID_PATH=pci-:03:00.0
>>
>> Are you telling me there are systems where this is not guaranteed to be
>> stable?
>
> Yes, including your own.
So biosdev is not guaranteed to be
On Mon, Apr 11, 2016 at 07:59:30PM +0200, Xen wrote:
> Greg KH schreef op 11-04-16 15:42:
> > On Mon, Apr 11, 2016 at 11:56:00AM +0200, Xen wrote:
> >> The predictability issue seems to be due to using a MAC address.
> >>
> >> AFAIK a reinstall will not change PCI bus devices etc.
> >
> > No, PCI
Greg KH schreef op 11-04-16 15:42:
> On Mon, Apr 11, 2016 at 11:56:00AM +0200, Xen wrote:
>> The predictability issue seems to be due to using a MAC address.
>>
>> AFAIK a reinstall will not change PCI bus devices etc.
>
> No, PCI device numbers change all the time, they are not guaranteed to
> be
On Mon, Apr 11, 2016 at 11:56:00AM +0200, Xen wrote:
> The predictability issue seems to be due to using a MAC address.
>
> AFAIK a reinstall will not change PCI bus devices etc.
No, PCI device numbers change all the time, they are not guaranteed to
be stable at all. Yes, lots of machines do not
Martin Pitt schreef op 11-04-16 10:40:
> Reindl Harald [2016-04-10 17:44 +0200]:
>>> Because we had a mechanism for stable (but not predictable) interfaces
>>> names, the 75-persistent-net-generator.rules thingy. Without either,
>>> the first time you plugged in a second card/USB dongle/add an ibmv
Am 11.04.2016 um 10:40 schrieb Martin Pitt:
Reindl Harald [2016-04-10 17:44 +0200]:
Because we had a mechanism for stable (but not predictable) interfaces
names, the 75-persistent-net-generator.rules thingy. Without either,
the first time you plugged in a second card/USB dongle/add an ibmveth
Reindl Harald [2016-04-10 17:44 +0200]:
> >Because we had a mechanism for stable (but not predictable) interfaces
> >names, the 75-persistent-net-generator.rules thingy. Without either,
> >the first time you plugged in a second card/USB dongle/add an ibmveth
> >etc., chaos would start.
>
> that wo
Am 10.04.2016 um 16:57 schrieb Martin Pitt:
Andrei Borzenkov [2016-04-10 11:31 +0300]:
It had been working out of the box for quite a lot of users actually.
Because we had a mechanism for stable (but not predictable) interfaces
names, the 75-persistent-net-generator.rules thingy. Without eit
Thank you Andrei and Reindl for your answers.
Let's stick to the facts for the moment or as much of it as we can.
Martin Pitt schreef op 10-04-16 10:17:
> There are very good reasons for having a mechanism for stable names by
> default. Most importantly, to keep your machine actually
> booting
Andrei Borzenkov [2016-04-10 11:31 +0300]:
> It had been working out of the box for quite a lot of users actually.
Because we had a mechanism for stable (but not predictable) interfaces
names, the 75-persistent-net-generator.rules thingy. Without either,
the first time you plugged in a second card
Am 10.04.2016 um 10:17 schrieb Martin Pitt:
Any user running a system with multiple NICs should be willing and
capable of choosing and assigning these names.
To be frank, this is the attitude of the 90's when you had to sit down
with a thick book and spend a week until your Linux system was u
10.04.2016 11:17, Martin Pitt пишет:
> Hello,
>
> Xen [2016-04-09 20:29 +0200]:
>> 1. I believe most users do not like the "enp5s0" scheme
>> 2. I do not think there are any good reasons for making it the default.
>
> There are very good reasons for having a mechanism for stable names by
> defaul
Hello,
Xen [2016-04-09 20:29 +0200]:
> 1. I believe most users do not like the "enp5s0" scheme
> 2. I do not think there are any good reasons for making it the default.
There are very good reasons for having a mechanism for stable names by
default. Most importantly, to keep your machine actually
I just want to add another opinion, but I am going to keep it really short.
1. I believe most users do not like the "enp5s0" scheme
2. I do not think there are any good reasons for making it the default.
As a single illustration, I will cite this reason from the website:
"Finally, many distribut
20 matches
Mail list logo
