Re: Sometimes different network interface name?

[Anssi Saari]

David Wright  writes:

> If you look at how the package iwd keeps the kernel's choice of name,
> you'll see it installs:

[...]

Interesting. I can't say I'm convinced by the systemd.link manpage that
this is the correct configuration but let's assume the iwd peeps know
what they're doing. I set this up since it's so simple. For the record,
the type for this interface is wwan. I'll try a few reboots at some
quiet time.

Re: Sometimes different network interface name?

[David Wright]

On Fri 02 Sep 2022 at 13:44:24 (+0300), Anssi Saari wrote:
> 
> I have an LTE module in my Debian router for failover in case my fiber
> goes down. It has this occasional issue that mostly its interface is
> wwan0 but sometimes it's wwx0a697e2d934f.
> 
> When that happens I have something like this in my syslog:
> 
>   Sep  1 08:34:40 animus kernel: [8.150781] qmi_wwan 2-1.3:1.5 
> wwx0a697e2d934f: renamed from wwan0
> 
> So did the kernel really go and rename my interface? Why does this
> happen only occasionally? Some race condition? And how can I put a stop
> to it? Should I use a .link file to make sure? I guess I could put
> something like this in a link file:
> 
> [Match]
> Path=pci-:00:13.0-usb-0:1.3:1.5
> 
> [Link]
> Name=wwan0
> 
> The Path parameter is from udevadm output. I think that path should be
> stable if I don't feel the need to move the LTE module to a different
> miniPCI slot and that's fairly unlikely.
> 
> I can query the interface name from the device and pass it around but
> that seems like the wrong thing to do and there are three things that
> need to know the interface.

If you look at how the package iwd keeps the kernel's choice of name,
you'll see it installs:

  $ cat /lib/systemd/network/80-iwd.link 
  [Match]
  Type=wlan

  [Link]
  NamePolicy=keep kernel
  $ 

so I would type:

  $ networkctl list
  IDX LINK  TYPE OPERATIONAL SETUP
1 loloopback carrier unmanaged
3 wlan0 wlan routableunmanaged

  2 links listed.
  $ 

to get the Type, and then create /etc/systemd/network/80-lte.link
with contents similar to the above, but the appropriate Type.
(Or, of course, you could name it with a name of your choosing.)

Cheers,
David.

Re: Sometimes different network interface name?

[Anssi Saari]

Tixy  writes:

> The number in the name looks like a MAC address and its value is in the
> 'locally administered' range, i.e. not something baked into the device
> by the manufacturer.

It's an LTE device so it doesn't have a MAC address even though it
presents an ethernet-like interface. Or I guess it's the qmi-wwan driver
which does that. Random generation seems likely since the number is not
the device serial or IMEI, at least.

> Is that number always the same?

It's only happened twice so far, the other time it was wwx0a87b909a663
instead of wwx0a697e2d934f so probably random.

> I'm wondering if there is a MAC randomisation process running on you
> system (sometimes used for privacy concerns) and that randomisation
> may be during boot with different timing compared to systemd/udev
> renaming the device from wwan0.

I'd assume no, other interfaces don't seem to be affected. I definitely
didn't install anything like that so only if it's a default in Debian.

Re: Sometimes different network interface name?

[Tixy]

On Fri, 2022-09-02 at 13:44 +0300, Anssi Saari wrote:
> I have an LTE module in my Debian router for failover in case my fiber
> goes down. It has this occasional issue that mostly its interface is
> wwan0 but sometimes it's wwx0a697e2d934f.
> 
> When that happens I have something like this in my syslog:
> 
>   Sep  1 08:34:40 animus kernel: [8.150781] qmi_wwan 2-1.3:1.5 
> wwx0a697e2d934f: renamed from wwan0
> 
> So did the kernel really go and rename my interface? Why does this
> happen only occasionally? Some race condition?

The number in the name looks like a MAC address and its value is in the
'locally administered' range, i.e. not something baked into the device
by the manufacturer. Is that number always the same? I'm wondering if
there is a MAC randomisation process running on you system (sometimes
used for privacy concerns) and that randomisation may be during boot
with different timing compared to systemd/udev renaming the device from
wwan0.

-- 
Tixy

Re: Sometimes different network interface name?

[Brian]

On Fri 02 Sep 2022 at 13:44:24 +0300, Anssi Saari wrote:

> 
> I have an LTE module in my Debian router for failover in case my fiber
> goes down. It has this occasional issue that mostly its interface is
> wwan0 but sometimes it's wwx0a697e2d934f.
> 
> When that happens I have something like this in my syslog:
> 
>   Sep  1 08:34:40 animus kernel: [8.150781] qmi_wwan 2-1.3:1.5 
> wwx0a697e2d934f: renamed from wwan0

Try the effect of stopping renaming by editing GRUB before booting
and adding

  net.ifnames=0

to the end of the linux line.

-- 
Brian.

Sometimes different network interface name?

[Anssi Saari]

I have an LTE module in my Debian router for failover in case my fiber
goes down. It has this occasional issue that mostly its interface is
wwan0 but sometimes it's wwx0a697e2d934f.

When that happens I have something like this in my syslog:

  Sep  1 08:34:40 animus kernel: [8.150781] qmi_wwan 2-1.3:1.5 
wwx0a697e2d934f: renamed from wwan0

So did the kernel really go and rename my interface? Why does this
happen only occasionally? Some race condition? And how can I put a stop
to it? Should I use a .link file to make sure? I guess I could put
something like this in a link file:

[Match]
Path=pci-:00:13.0-usb-0:1.3:1.5

[Link]
Name=wwan0

The Path parameter is from udevadm output. I think that path should be
stable if I don't feel the need to move the LTE module to a different
miniPCI slot and that's fairly unlikely.

I can query the interface name from the device and pass it around but
that seems like the wrong thing to do and there are three things that
need to know the interface.

Re: Predictable Network Interface Names

[Anssi Saari]

Erwan David  writes:

> I also got a name change with an upgrade (I do not remember wether it
> was kernel, systemd or udev).
>
> SInce interfaces where combined in a bond, imagine the mess...

I think I noticed something like that too as I've updated my desktop HW
and booted from some different media. Not a big deal on the desktop but
I have to say I don't much ilke the enpXsY scheme. I guess I'll be going
to eth0 on systems with one wired interface and wlan0 if there's single
wireless interface. Which means my desktop, stuff server and my two
currently working Raspberry Pis.

Not so sure what to do with other systems that have multiple
interfaces. My file server has three, router has four or four and a half
since there's an LTE module which presents as "kinda" ethernet. On the
router especially my firewall rules depend on interface names.

Re: Predictable Network Interface Names

[Cindy Sue Causey]

On 3/30/22, Dan Ritter  wrote:
> Greg Wooledge wrote:
>> On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
>> > That's good advice, but are MAC addresses memorable?
>>
>> Doesn't matter.  You can choose a memorable name.  The MAC address is
>> simply the data point you place in the config file, so the system knows
>> this is the interface you're talking about.
>>
>> unicorn:~$ cat /etc/systemd/network/10-lan0.link
>> [Match]
>> MACAddress=18:60:24:77:5c:ec
>>
>> [Link]
>> Name=lan0
>>
>> That's what I'm using.  Of course, this relies on the MAC address being
>> consistent across boots.  I've heard of some cases where this isn't
>> true, but I believe those cases involved removable devices (USB network
>> interfaces or similar).
>
> Some NICs can have their MAC addresses changed permanently.
>
> There were at least a few terrible NICs in history where an
> entire production run got the same MAC address assigned.
>
> Most NICs can have their MAC addresses reassigned after boot,
> which will almost always be reset on next power cycle.
>
> lan0 is a good name. I like names like "internal" and "dmz" and  "internet"
> or "cogent" and "level3" -- either functional descriptors or
> where their other ends are connected.


macchanger.. I tried it a couple years ago for some forgotten reason.
I think it was when the names first started changing on us, and I was
trying to take control of the situation. I remember it working and
then not working. Can't remember now why I gave up on it. Thankfully
things have ironed out some since so it hasn't been needed in my usage
case.

>From "apt-cache show," it seems to reference the same vendor MAC
duplication instances (Point #4):

Features:
 .
   * set specific MAC address of a network interface
   * set the MAC randomly
   * set a MAC of another vendor
   * set another MAC of the same vendor
   * set a MAC of the same kind (eg: wireless card)
   * display a vendor MAC list (today, 6200 items) to choose from

Afterthought, my problems eased up after I figured out I could grep
dmesg for "renamed from" and plug that result into where I needed the
name. Tripped over that by accident. Might have started out grepping
for eth0, maybe.

Have fun!

Cindy :)
-- 
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

Re: Predictable Network Interface Names

[tomas]

On Thu, Mar 31, 2022 at 08:04:13AM -0400, Michael Stone wrote:
> On Thu, Mar 31, 2022 at 07:10:33AM +0200, to...@tuxteam.de wrote:
> > Somewhat self-referential. I'm not the one getting worked up here ;-)
> 
> And I'm not the one accusing people of lying.

I hope my clarification --uh-- clears things up.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Predictable Network Interface Names

[tomas]

On Thu, Mar 31, 2022 at 12:39:37PM +0100, Brian wrote:
> On Thu 31 Mar 2022 at 07:28:47 +0200, to...@tuxteam.de wrote:
> 
> [...]]
> 
> > Since then, I learnt that I like to relax call my interfaces
> > "eth0" and "wlan0".
> > 
> > Can we still be friends?
> 
> Of course! After all, we are both playing in the same game.

Glad :)

(No, seriously: I might sound somewhat sarcastic, but my relief is genuine)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Predictable Network Interface Names

[Michael Stone]

On Thu, Mar 31, 2022 at 07:10:33AM +0200, to...@tuxteam.de wrote:

Somewhat self-referential. I'm not the one getting worked up here ;-)


And I'm not the one accusing people of lying.

Re: Predictable Network Interface Names

[The Wanderer]

On 2022-03-31 at 01:28, to...@tuxteam.de wrote:

> This is one weakness I see with freedesktop often. They try to
> fight complexity with ever more complexity, with the end result
> of a more user-unfriendly (because less understandable) system.

Very well expressed. I've added that to the "complete" edition of my
signature (although I rotate out the pieces so rarely that I'd guess it
might see the light of day... sometime in the next decade?).

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Predictable Network Interface Names

[Michael Stone]

On Wed, Mar 30, 2022 at 05:56:47PM -0500, Nicholas Geovanis wrote:

Because some of us work in corporate data centers. And everything you claim
that helps us here really does the opposite. Because it was introduced in large
part to support mobile computing. Which does not and will never be valuable on
the back-end, the server end, where commerce occurs.


Weird, because it works fine for me in that use case.

Re: Predictable Network Interface Names

[Brian]

On Thu 31 Mar 2022 at 07:28:47 +0200, to...@tuxteam.de wrote:

[...]]

> Since then, I learnt that I like to relax call my interfaces
> "eth0" and "wlan0".
> 
> Can we still be friends?

Of course! After all, we are both playing in the same game.

-- 
Brian.

Re: Predictable Network Interface Names

[Markus Schönhaber]

31.03.22, 13:01 +0200, Sven Hartge:


Greg Wooledge  wrote:


unicorn:~$ cat /etc/systemd/network/10-lan0.link
[Match]
MACAddress=18:60:24:77:5c:ec



[Link]
Name=lan0


Careful with that one. If you use VLANs then you suddenly get multiple
interface with the same MAC and strange things will happen, because it
matches for all of them.

The failure-proof way of doing this is by adding "Type=ether" to the
Match clause, which will only match the physical interfaces and not the
subinterfaces. (Which will be of Type=vlan.):


Since I haven't (yet) used the combination VLAN/systemd.link I haven't 
run into this issue. But it is definitely something to keep in mind.

Thanks for the hint!

--
Regards
  mks

Re: Predictable Network Interface Names

[Sven Hartge]

Greg Wooledge  wrote:

> unicorn:~$ cat /etc/systemd/network/10-lan0.link 
> [Match]
> MACAddress=18:60:24:77:5c:ec

> [Link]
> Name=lan0

Careful with that one. If you use VLANs then you suddenly get multiple
interface with the same MAC and strange things will happen, because it
matches for all of them.

The failure-proof way of doing this is by adding "Type=ether" to the
Match clause, which will only match the physical interfaces and not the
subinterfaces. (Which will be of Type=vlan.):

,
| [Match]
| MACAddress=18:60:24:77:5c:ec
| Type=ether
|
| [Link]
| Name=lan0
`

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: Predictable Network Interface Names

[tomas]

On Wed, Mar 30, 2022 at 10:38:10PM +0100, Brian wrote:
> On Wed 30 Mar 2022 at 21:50:53 +0200, to...@tuxteam.de wrote:
> 
> > On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> > > On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:
> > > 
> > > > On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote:
> > > > > as I can read here [1] network names should be stable.
> > > > > (Stable interface names even when hardware is added or removed)
> > > > 
> > > > > [1] 
> > > > > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> > > > 
> > > > Sorry, but you've been lied to.
> > > 
> > > I would see that as a bit strong. A lie is a deliberate action,
> > > knowing the reality rests elesewhere. Good faith and all that :).
> > 
> > Perhaps.
> 
> Perhaps? Perhaps what? Perhaps it is a lie? freedesktop conceals
> the truth and peddles false information purposefully?

Calm down. There are many shades between Truth (TM) and Lie (TM).
My take is that this specific shade is failing to admit that the
freedesktop folks set out to solve a generally unsolvable problem.

This is one weakness I see with freedesktop often. They try to
fight complexity with ever more complexity, with the end result
of a more user-unfriendly (because less understandable) system.

Nevertheless I thank freedesktop for keeping X (which I do use
a lot) up and running. It's not that I hate them (much less the
people working there). I'm thankful.

Good intentions, pavements, hell, all that.

But hey, this is my take. I'm not in the mood to wage a war over
it. You get to keep your take, I get to keep mine. We could even
remain friends over that.

> > But once I understood what problem this is trying to solve,
> > and how, I decided I haven't that problem, I have net.ifnames=0 in
> > my GRUB_CMDLINE_LINUX_DEFAULT, in /etc/default/grub.
> 
> Well done! But, if there isn't any problem for you, why go to this
> trouble? Leaving things as they are would seem not to do any harm.

To what trouble? Adding a boot option to my kernel? The trouble
was to find out which one. After that, I'm a happy camper :)

See, for an anecdote: long time ago (this was Linux kernel 2.0.36)
a group of us customised a distro (yes, it was a Debian. Must
have been around Potato or Woody) for a local hardware vendor.
It was a firewall appliance, with four network cards. One of
the ethernet ports was labelled "Internet", the other three "internal
net".

Guess which kind of problem we faced?

After a dive into the PCI spec, the specs of the motherboard
we used at the time, etc. we reached the conclusion that there
is no way to be sure we know which is which (if you follow the
thread here you'll discover exactly that pattern, years down
the history). PCI slots ain't it, because, at the end, hardware
does what it wants. Things become even worse when devices are
hanging off an USB tree. MACs? Some cards are chamaleons and
can change that [1] on the fly. Some can even have more than
one. Yadda, yadda.

Since then, I learnt that I like to relax call my interfaces
"eth0" and "wlan0".

Can we still be friends?

Cheers

[1] I won't bore you with /that/ anecdote, although it's
   funny :)

-- 
t


signature.asc
Description: PGP signature

Re: Predictable Network Interface Names

[tomas]

On Wed, Mar 30, 2022 at 05:55:11PM -0400, Michael Stone wrote:
> On Wed, Mar 30, 2022 at 10:38:10PM +0100, Brian wrote:
> > Perhaps? Perhaps what? Perhaps it is a lie? freedesktop conceals
> > the truth and peddles false information purposefully?
> 
> Some people get excessively worked up over things like interface names and
> like to throw around strong words for dramatic effect. Just ignore the
> noise.

Somewhat self-referential. I'm not the one getting worked up here ;-)

Let's not quarrel over it. You like your predictable names. I like
mine. Let's Just Get Along (TM) :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Predictable Network Interface Names

[gene heskett]

On Wednesday, 30 March 2022 18:31:36 EDT Michael Stone wrote:
> On Wed, Mar 30, 2022 at 06:19:17PM -0400, Greg Wooledge wrote:
> >It's like you haven't even read this thread.
> 
> of course I have
> 
> >Predictable interface names *do* sometimes change.  And when that
> >happens, it's a huge deal, because all of the configuration files are
> >set up for the old name.  Things break, in an extremely visible way.
> 
> And they also broke before the predictable name scheme! And they can
> break if you lock names to MAC addresses! There are always ways things
> can break. If they break in an extremely visible way that's actually a
> good thing--the impact of simple interface reordering can be much more
> severe. And when they do break, the fix is generally pretty
> straightforward (that is, not such a big deal as to justify the bytes
> wasted complaining about it).
> 
> >This is not some theoretical issue.  This is real.
> 
> It's also real that for the majority of systems it works fine. Why are
> you so invested in denying that reality?
> 
Perhaps because to the OP, it is a big deal, being locked away from the 
info that makes it and easy fix. I'm one that that fairly numerous crowd 
who has suffered thru fixing that, but from reading the mail for 20 some 
years, I've learned that complaining is a waste of time, the coder are 
gonna do it their way regardless of the crowd wanting blood. So I don't, 
until this attitude pushes my button.

Take care and stay well, thats more important than complaining to a stone 
wall today.

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: Predictable Network Interface Names

[Intense Red]

> Some people get excessively worked up over things like interface names
> and like to throw around strong words for dramatic effect. Just ignore
> the noise.

   I've just come to accept that the actual interface name is going to be some 
bizarre name. So I look it up, and then promptly rename it in "/etc/network/
interfaces" like so:

 - - - snip - - -
iface enp18s0f0 inet manual

auto LAN
iface LAN inet static
address 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.1.1
dns-nameservers 192.168.168.1
dns-search locallan.net
bridge_ports enp18s0f0
 - - - snip - - -

   This uses Debian's bridge-utils package to rename the interface.

   From then on, my machines have an interface named LAN, WAN, DMZ, etc. -- 
all "logical" names and I don't have to deal with enp18s0f0 or enp18s1e0 or 
some such nonsense.


-- 
"When law and morality contradict each other, the citizen has the cruel 
alternative of either losing his moral sense or losing his respect for the 
law." -- Frederic Bastiat, 19th century French author and economist.

Re: Predictable Network Interface Names

[Nicholas Geovanis]

On Wed, Mar 30, 2022, 5:32 PM Michael Stone  wrote:

> On Wed, Mar 30, 2022 at 06:19:17PM -0400, Greg Wooledge wrote:
> >It's like you haven't even read this thread.
>
> of course I have
>
> >Predictable interface names *do* sometimes change.  And when that happens,
> >it's a huge deal, because all of the configuration files are set up for
> >the old name.  Things break, in an extremely visible way.
>
> And they also broke before the predictable name scheme! And they can
> break if you lock names to MAC addresses! There are always ways things
> can break. If they break in an extremely visible way that's actually a
> good thing--the impact of simple interface reordering can be much more
> severe. And when they do break, the fix is generally pretty
> straightforward (that is, not such a big deal as to justify the bytes
> wasted complaining about it).
>
> >This is not some theoretical issue.  This is real.
>
> It's also real that for the majority of systems it works fine. Why are
> you so invested in denying that reality?
>

Because some of us work in corporate data centers. And everything you claim
that helps us here really does the opposite. Because it was introduced in
large part to support mobile computing. Which does not and will never be
valuable on the back-end, the server end, where commerce occurs.

It's what we call a different "use-case".

>

Re: Predictable Network Interface Names

[Michael Stone]

On Wed, Mar 30, 2022 at 06:19:17PM -0400, Greg Wooledge wrote:

It's like you haven't even read this thread.


of course I have


Predictable interface names *do* sometimes change.  And when that happens,
it's a huge deal, because all of the configuration files are set up for
the old name.  Things break, in an extremely visible way.


And they also broke before the predictable name scheme! And they can 
break if you lock names to MAC addresses! There are always ways things 
can break. If they break in an extremely visible way that's actually a 
good thing--the impact of simple interface reordering can be much more 
severe. And when they do break, the fix is generally pretty 
straightforward (that is, not such a big deal as to justify the bytes 
wasted complaining about it).



This is not some theoretical issue.  This is real.


It's also real that for the majority of systems it works fine. Why are 
you so invested in denying that reality?

Re: Predictable Network Interface Names

[Greg Wooledge]

On Wed, Mar 30, 2022 at 05:55:11PM -0400, Michael Stone wrote:
> For most consumer sytems the interface name matters not one bit, because
> it's auto-discovered on install, will never change, and there's little
> likelihood that another interface will be added.

It's like you haven't even read this thread.

Predictable interface names *do* sometimes change.  And when that happens,
it's a huge deal, because all of the configuration files are set up for
the old name.  Things break, in an extremely visible way.

This is not some theoretical issue.  This is real.

Re: Predictable Network Interface Names

[Michael Stone]

On Wed, Mar 30, 2022 at 10:38:10PM +0100, Brian wrote:

Perhaps? Perhaps what? Perhaps it is a lie? freedesktop conceals
the truth and peddles false information purposefully?


Some people get excessively worked up over things like interface names 
and like to throw around strong words for dramatic effect. Just ignore 
the noise.


We've been over all this before. In general, for server-class systems, 
predictable interface names Just Work. These are the kinds of systems 
mostly likely to have 1) lots of interfaces and 2) a need for 
standardized build profiles. I've got quite a lot of these in 
production, and it works as advertised. One really nice thing this gets 
you that MAC-based renamed interfaces can't (apart from not needing to 
plug hundreds of MAC addresses into config files) is that when a NIC 
goes bad and you pop in a replacement...it has the same name. 

For most consumer sytems the interface name matters not one bit, because 
it's auto-discovered on install, will never change, and there's little 
likelihood that another interface will be added.


Then there's a small sliver of systems whose users like to shuffle 
things around, but for some reason can't stand having to learn anything 
new or change a config file or whatever, so they get unbelievably angry 
about a rather sensible naming scheme and throw out hot words like 
"lies" rather than just getting on with their lives. You'd think they'd 
just set their defaults the way they want them instead of venting on 
mailing lists, but the internet is the internet.

Re: Predictable Network Interface Names

[Brian]

On Wed 30 Mar 2022 at 21:50:53 +0200, to...@tuxteam.de wrote:

> On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> > On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:
> > 
> > > On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote:
> > > > as I can read here [1] network names should be stable.
> > > > (Stable interface names even when hardware is added or removed)
> > > 
> > > > [1] 
> > > > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> > > 
> > > Sorry, but you've been lied to.
> > 
> > I would see that as a bit strong. A lie is a deliberate action,
> > knowing the reality rests elesewhere. Good faith and all that :).
> 
> Perhaps.

Perhaps? Perhaps what? Perhaps it is a lie? freedesktop conceals
the truth and peddles false information purposefully?

> But once I understood what problem this is trying to solve,
> and how, I decided I haven't that problem, I have net.ifnames=0 in
> my GRUB_CMDLINE_LINUX_DEFAULT, in /etc/default/grub.

Well done! But, if there isn't any problem for you, why go to this
trouble? Leaving things as they are would seem not to do any harm.

-- 
Brian.

Re: Predictable Network Interface Names

[Greg Wooledge]

On Wed, Mar 30, 2022 at 04:00:42PM -0500, Nicholas Geovanis wrote:
> Does anyone here know how the BSD-derived "free" unices handle this
> situation?

I haven't used OpenBSD in several years, but the last time I used it,
it went something like this:

The OpenBSD kernel has drivers for lots of different kinds of network
interfaces.  Each driver has a separate concise name.  Some examples:

  ath — Atheros IEEE 802.11a/b/g wireless network device with GPIO
  fxp — Intel EtherExpress PRO/100 10/100 Ethernet device
  ie — Intel i82596 Ethernet device
  rl — Realtek 8129/8139 10/100 Ethernet device

When the kernel boots and does its hardware detection, any devices that
are detected are "claimed" by the appropriate drivers, and given a name
according to the driver which claims it.  E.g. if the system has one
Realtek 8129 interface, that interface will be named "rl0", regardless
of whether it's detected before or after an Intel PRO/100, which is
claimed by the fxp driver and named "fxp0".

As long as there's only one interface claimed by each driver, there will
never be any unpredictability in the names.

I'm not sure how it handles the naming when there are two or more
interfaces claimed by the same driver.  They'll be called "rl0" and "rl1"
for example, but I don't know how it determines which one gets which
name.

Re: Predictable Network Interface Names

[Nicholas Geovanis]

On Wed, Mar 30, 2022, 2:15 PM Brian  wrote:

> On Wed 30 Mar 2022 at 14:39:33 -0400, Greg Wooledge wrote:
>
> > On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> > > On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:
> > > > Yes.  You've now seen direct evidence of the lie.  I guess I won't
> need
> > > > to post links to the wiki articles that say the same thing you've
> already
> > > > observed.
> > >
> > > I would be interested in a couple of links to the same observations
> > > as given by the OP.
> >
> > <
> https://wiki.debian.org/NetworkInterfaceNames#Complications_and_corner_cases
> >
> > tries very hard to avoid mentioning the issue directly, but ultimately
> > has this paragraph down near the bottom of the section:
> >
> >   it turns out even after all this there are still reported cases of
> >   interfaces changing their name on a reboot. All that needs to happen
> >   is that some buggy BIOS (or some new, less buggy version of a driver
> >   module, or systemd's naming policy) changes its mind about some detail
> >   like whether or not your hardware counts as the kind that should have
> >   an ONBOARD name. There are even reports of devices changing their
> >   PCI-port numbering due to other hardware being installed.
> >
> > This links to
> >  which
> > goes into some detail.
>
> Thanks. Very informative. As the second link says:
>
>   The resulting reality is that your PCI based names are only
>   stable if you change no hardware in the system. The moment
>   you change any hardware all bets are off for all hardware.
>
> This, plus your advice, could point the OP to a way forward.
>
> How hardare specific the claim is is not explored.
>
> > I'm sure there are many more pages like this one.
> >
> > > Recently, we have had a mail or two about iwd. It uses the kernel
> > > interface wlan0, which broke my /e/n/i. In the end I went with the
> > > flow on the basis that wlan0 is stable enough and changed /e/n/i
> > > rather than fighting iwd.
> >
> > Wireless interfaces are not my strong suit.  I don't have any advice
> > for those.
>
> I only mentioned what I did bcause, om the whole, I am prepared to
> accept interface renaming. The vast majority of users will not notice
> that it has taken place.
>

Does anyone here know how the BSD-derived "free" unices handle this
situation?
And how about free-ish Oracle/Solaris?
And AIX running on Intel hard/firmware?

-- 
> Brian.
>
>

Re: Predictable Network Interface Names

[tomas]

On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:
> 
> > On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote:
> > > as I can read here [1] network names should be stable.
> > > (Stable interface names even when hardware is added or removed)
> > 
> > > [1] 
> > > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> > 
> > Sorry, but you've been lied to.
> 
> I would see that as a bit strong. A lie is a deliberate action,
> knowing the reality rests elesewhere. Good faith and all that :).

Perhaps. But once I understood what problem this is trying to solve,
and how, I decided I haven't that problem, I have net.ifnames=0 in
my GRUB_CMDLINE_LINUX_DEFAULT, in /etc/default/grub.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Predictable Network Interface Names

[Dan Ritter]

Greg Wooledge wrote: 
> On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> > That's good advice, but are MAC addresses memorable?
> 
> Doesn't matter.  You can choose a memorable name.  The MAC address is
> simply the data point you place in the config file, so the system knows
> this is the interface you're talking about.
> 
> unicorn:~$ cat /etc/systemd/network/10-lan0.link 
> [Match]
> MACAddress=18:60:24:77:5c:ec
> 
> [Link]
> Name=lan0
> 
> That's what I'm using.  Of course, this relies on the MAC address being
> consistent across boots.  I've heard of some cases where this isn't
> true, but I believe those cases involved removable devices (USB network
> interfaces or similar).

Some NICs can have their MAC addresses changed permanently.

There were at least a few terrible NICs in history where an
entire production run got the same MAC address assigned.

Most NICs can have their MAC addresses reassigned after boot,
which will almost always be reset on next power cycle.

lan0 is a good name. I like names like "internal" and "dmz" and  "internet"
or "cogent" and "level3" -- either functional descriptors or
where their other ends are connected.

-dsr-

Re: Predictable Network Interface Names

[Erwan David]

Le 30/03/2022 à 21:15, Brian a écrit :

= which

goes into some detail.

Thanks. Very informative. As the second link says:

   The resulting reality is that your PCI based names are only
   stable if you change no hardware in the system. The moment
   you change any hardware all bets are off for all hardware.

This, plus your advice, could point the OP to a way forward.



I also got a name change with an upgrade (I do not remember wether it 
was kernel, systemd or udev).


SInce interfaces where combined in a bond, imagine the mess...

Re: Predictable Network Interface Names

[Brian]

On Wed 30 Mar 2022 at 14:39:33 -0400, Greg Wooledge wrote:

> On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> > On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:
> > > Yes.  You've now seen direct evidence of the lie.  I guess I won't need
> > > to post links to the wiki articles that say the same thing you've already
> > > observed.
> > 
> > I would be interested in a couple of links to the same observations
> > as given by the OP.
> 
> 
> tries very hard to avoid mentioning the issue directly, but ultimately
> has this paragraph down near the bottom of the section:
> 
>   it turns out even after all this there are still reported cases of
>   interfaces changing their name on a reboot. All that needs to happen
>   is that some buggy BIOS (or some new, less buggy version of a driver
>   module, or systemd's naming policy) changes its mind about some detail
>   like whether or not your hardware counts as the kind that should have
>   an ONBOARD name. There are even reports of devices changing their
>   PCI-port numbering due to other hardware being installed.
> 
> This links to
>  which
> goes into some detail.

Thanks. Very informative. As the second link says:

  The resulting reality is that your PCI based names are only
  stable if you change no hardware in the system. The moment
  you change any hardware all bets are off for all hardware.

This, plus your advice, could point the OP to a way forward.

How hardare specific the claim is is not explored.
 
> I'm sure there are many more pages like this one.
> 
> > Recently, we have had a mail or two about iwd. It uses the kernel
> > interface wlan0, which broke my /e/n/i. In the end I went with the
> > flow on the basis that wlan0 is stable enough and changed /e/n/i
> > rather than fighting iwd.
> 
> Wireless interfaces are not my strong suit.  I don't have any advice
> for those.

I only mentioned what I did bcause, om the whole, I am prepared to
accept interface renaming. The vast majority of users will not notice
that it has taken place.

-- 
Brian.

Re: Predictable Network Interface Names

[Erwan David]

Le 30/03/2022 à 20:39, Greg Wooledge a écrit :


Doesn't matter.  You can choose a memorable name.  The MAC address is
simply the data point you place in the config file, so the system knows
this is the interface you're talking about.

unicorn:~$ cat /etc/systemd/network/10-lan0.link
[Match]
MACAddress=18:60:24:77:5c:ec

[Link]
Name=lan0

That's what I'm using.  Of course, this relies on the MAC address being
consistent across boots.  I've heard of some cases where this isn't
true, but I believe those cases involved removable devices (USB network
interfaces or similar).

"lan0" is familiar to me from HP-UX, and it also isn't "eth0", so there's
no risk of collision with the kernel's default name scheme.  I have
no idea what happens if you try to assign the names "eth0" and "eth1"
to a pair of interfaces that come up as "eth1" and "eth0" by default.
Are the renames done sequentially?  Will they fail in this case?  I don't
know, and I don't want to find out the hard way.


Be aware that bridge or bond interfaces get their mac address from one 
of the inner inetrface, thus you may have to add a macth (eg a match on 
the driver)

Re: Predictable Network Interface Names

[Greg Wooledge]

On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:
> > Yes.  You've now seen direct evidence of the lie.  I guess I won't need
> > to post links to the wiki articles that say the same thing you've already
> > observed.
> 
> I would be interested in a couple of links to the same observations
> as given by the OP.


tries very hard to avoid mentioning the issue directly, but ultimately
has this paragraph down near the bottom of the section:

  it turns out even after all this there are still reported cases of
  interfaces changing their name on a reboot. All that needs to happen
  is that some buggy BIOS (or some new, less buggy version of a driver
  module, or systemd's naming policy) changes its mind about some detail
  like whether or not your hardware counts as the kind that should have
  an ONBOARD name. There are even reports of devices changing their
  PCI-port numbering due to other hardware being installed.

This links to
 which
goes into some detail.

I'm sure there are many more pages like this one.

> Recently, we have had a mail or two about iwd. It uses the kernel
> interface wlan0, which broke my /e/n/i. In the end I went with the
> flow on the basis that wlan0 is stable enough and changed /e/n/i
> rather than fighting iwd.

Wireless interfaces are not my strong suit.  I don't have any advice
for those.

> > 2) If you have multiple ethernet interfaces, or the possibility of this
> >occurring in the future, take control of their names yourself.  Set
> >up systemd.link(5) files to assign a name to each interface based on
> >its MAC address, or some other identifying characteristic.
> 
> That's good advice, but are MAC addresses memorable?

Doesn't matter.  You can choose a memorable name.  The MAC address is
simply the data point you place in the config file, so the system knows
this is the interface you're talking about.

unicorn:~$ cat /etc/systemd/network/10-lan0.link 
[Match]
MACAddress=18:60:24:77:5c:ec

[Link]
Name=lan0

That's what I'm using.  Of course, this relies on the MAC address being
consistent across boots.  I've heard of some cases where this isn't
true, but I believe those cases involved removable devices (USB network
interfaces or similar).

"lan0" is familiar to me from HP-UX, and it also isn't "eth0", so there's
no risk of collision with the kernel's default name scheme.  I have
no idea what happens if you try to assign the names "eth0" and "eth1"
to a pair of interfaces that come up as "eth1" and "eth0" by default.
Are the renames done sequentially?  Will they fail in this case?  I don't
know, and I don't want to find out the hard way.

Re: Predictable Network Interface Names

[Brian]

On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:

> On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote:
> > as I can read here [1] network names should be stable.
> > (Stable interface names even when hardware is added or removed)
> 
> > [1] 
> > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> 
> Sorry, but you've been lied to.

I would see that as a bit strong. A lie is a deliberate action,
knowing the reality rests elesewhere. Good faith and all that :).
 
> > What I see now is:
> > 
> > When I add or remove a PCIe card (USB card) the name is changed from enp5s3
> > to enp6s3 and back for example.
> 
> Yes.  You've now seen direct evidence of the lie.  I guess I won't need
> to post links to the wiki articles that say the same thing you've already
> observed.

I would be interested in a couple of links to the same observations
as given by the OP.
> 
> For most people, there are two paths forward:
> 
> 1) If your system has exactly one ethernet interface, and if this is not
>likely to change at any point in the future, you can go back to the
>old old way of doing things -- let the kernel assign "eth0" to the
>first interface it finds, "eth1" to the second interface it finds,
>and so on.  Since it will only ever find one interface, that interface
>will always be named "eth0", and you can configure from there.

Recently, we have had a mail or two about iwd. It uses the kernel
interface wlan0, which broke my /e/n/i. In the end I went with the
flow on the basis that wlan0 is stable enough and changed /e/n/i
rather than fighting iwd.

If you were of the opinion that, with a single interface, a user
gets a stable. *easily memorable* name, I could agree with you.

> 2) If you have multiple ethernet interfaces, or the possibility of this
>occurring in the future, take control of their names yourself.  Set
>up systemd.link(5) files to assign a name to each interface based on
>its MAC address, or some other identifying characteristic.

That's good advice, but are MAC addresses memorable?

-- 
Brian.

Re: Predictable Network Interface Names

[Greg Wooledge]

On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote:
> as I can read here [1] network names should be stable.
> (Stable interface names even when hardware is added or removed)

> [1] 
> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Sorry, but you've been lied to.

> What I see now is:
> 
> When I add or remove a PCIe card (USB card) the name is changed from enp5s3
> to enp6s3 and back for example.

Yes.  You've now seen direct evidence of the lie.  I guess I won't need
to post links to the wiki articles that say the same thing you've already
observed.

For most people, there are two paths forward:

1) If your system has exactly one ethernet interface, and if this is not
   likely to change at any point in the future, you can go back to the
   old old way of doing things -- let the kernel assign "eth0" to the
   first interface it finds, "eth1" to the second interface it finds,
   and so on.  Since it will only ever find one interface, that interface
   will always be named "eth0", and you can configure from there.

2) If you have multiple ethernet interfaces, or the possibility of this
   occurring in the future, take control of their names yourself.  Set
   up systemd.link(5) files to assign a name to each interface based on
   its MAC address, or some other identifying characteristic.

Predictable Network Interface Names

[basti]

Hello,

as I can read here [1] network names should be stable.
(Stable interface names even when hardware is added or removed)

First of all I have multiple PCIe NIC in a server.

What I see now is:

When I add or remove a PCIe card (USB card) the name is changed from 
enp5s3 to enp6s3 and back for example.


This is not what I understand with "Stable interface names", especially
when it rename multiple nic's.

I guess an empty PCI / PCIe slot is ignored.

Is there a way to not ignore empty slots?

[1] 
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Re: Installer can't find network interface on Intel NUC BOXNUC8i3BEH1

[Rick Thomas]

> On Feb 13, 2019, at 6:51 PM, Rick Thomas  wrote:
> 
> 
> 
>> On Feb 13, 2019, at 5:47 PM, Ben Hutchings  wrote:
>> 
>> On Wed, 2019-02-13 at 16:17 -0500, Laurent Dumont wrote:
>>> I'm not sure if it's the exact same case but I had the same issue with a
>>> more recent motherboard. Debian failed to detect the network card with the
>>> E1000 drivers.
>>> 
>>> I tried an iso with the non free repo without success.
>>> 
>>> A base Ubuntu iso install was able to detect and configure the network
>>> driver.
>>> 
>>> I'll see if I can find the adapter version. It was an Intel based adapter.
>> [...]
>> 
>> Unfortunately the various chips supported by e1000e are all subtly
>> different and each new chip seems to need extra code in the driver. 
>> Debian 9 still has Linux 4.9 and we haven't backported those driver
>> changes.
>> 
>> There is supposed to be an optional installer build that uses a newer
>> kernel version, but that hasn't officially happened yet.
>> 
>> At this point you might be better off using the alpha release of the
>> installer for Debian 10 "buster".
>> 
>> Ben.
>> 
>> -- 
>> Ben Hutchings
>> When in doubt, use brute force. - Ken Thompson
> 
> Thanks, Ben!
> 
> I’ll give that a try!
> Rick

That works!  I used the amd64 “alpha5” image. I had to install the non-free 
firmware to get the wifi to work, but I probably would have done that anyway!

Thanks for your help!
Rick

Re: Installer can't find network interface on Intel NUC BOXNUC8i3BEH1

[Rick Thomas]

> On Feb 13, 2019, at 5:47 PM, Ben Hutchings  wrote:
> 
> On Wed, 2019-02-13 at 16:17 -0500, Laurent Dumont wrote:
>> I'm not sure if it's the exact same case but I had the same issue with a
>> more recent motherboard. Debian failed to detect the network card with the
>> E1000 drivers.
>> 
>> I tried an iso with the non free repo without success.
>> 
>> A base Ubuntu iso install was able to detect and configure the network
>> driver.
>> 
>> I'll see if I can find the adapter version. It was an Intel based adapter.
> [...]
> 
> Unfortunately the various chips supported by e1000e are all subtly
> different and each new chip seems to need extra code in the driver. 
> Debian 9 still has Linux 4.9 and we haven't backported those driver
> changes.
> 
> There is supposed to be an optional installer build that uses a newer
> kernel version, but that hasn't officially happened yet.
> 
> At this point you might be better off using the alpha release of the
> installer for Debian 10 "buster".
> 
> Ben.
> 
> -- 
> Ben Hutchings
> When in doubt, use brute force. - Ken Thompson

Thanks, Ben!

I’ll give that a try!
Rick

Re: Installer can't find network interface on Intel NUC BOXNUC8i3BEH1

[Ben Hutchings]

On Wed, 2019-02-13 at 16:17 -0500, Laurent Dumont wrote:
> I'm not sure if it's the exact same case but I had the same issue with a
> more recent motherboard. Debian failed to detect the network card with the
> E1000 drivers.
> 
> I tried an iso with the non free repo without success.
> 
> A base Ubuntu iso install was able to detect and configure the network
> driver.
> 
> I'll see if I can find the adapter version. It was an Intel based adapter.
[...]

Unfortunately the various chips supported by e1000e are all subtly
different and each new chip seems to need extra code in the driver. 
Debian 9 still has Linux 4.9 and we haven't backported those driver
changes.

There is supposed to be an optional installer build that uses a newer
kernel version, but that hasn't officially happened yet.

At this point you might be better off using the alpha release of the
installer for Debian 10 "buster".

Ben.

-- 
Ben Hutchings
When in doubt, use brute force. - Ken Thompson




signature.asc
Description: This is a digitally signed message part

Re: Installer can't find network interface on Intel NUC BOXNUC8i3BEH1

[Laurent Dumont]

I'm not sure if it's the exact same case but I had the same issue with a
more recent motherboard. Debian failed to detect the network card with the
E1000 drivers.

I tried an iso with the non free repo without success.

A base Ubuntu iso install was able to detect and configure the network
driver.

I'll see if I can find the adapter version. It was an Intel based adapter.

On Wed, Feb 13, 2019, 4:12 PM Rick Thomas  I recently bought an intel NUC BOXNUC8i3BEH1.  You can see a description
> of the product at Newegg:
> https://www.newegg.com/Product/Product.aspx?Item=N82E16856102213
>
> I’m trying to install Debian Stretch on it
> debian-9.7.0-amd64-DVD-1.iso
> and (later)
> firmware-9.6.0-amd64-DVD-1.iso
>
> I made a bootable USB stick the usual way with dd to copy the iso to the
> stick.  It boots fine and loads some preliminary stuff.  When it gets to
> trying to identify the network interface, it fails at that task and drops
> into a screen with a long list of network drivers for me to choose from.
>
> I didn’t know what driver to load (the Newegg description says it uses an
> Intel networking chip, but I didn’t know which driver was needed by that
> chip)  So I aborted the installation.  On a hunch, I then tried to install
> Ubuntu (ubuntu-mate-18.04-desktop-amd64.iso) and that works fine.  The
> network comes up automatically.
>
> So, on Ubuntu, I typed “lspci -v” and searched the output for the network
> interface.  It says that the driver installed for that interface is
> “e1000e”.  A quick check on a working Stretch system shows that the e1000e
> driver *is* available in Debian.  So, I think to myself, “Problem solved —
> all I have to do is specify the e1000e driver and all will be well!”
>
> Not so fast…  I boot the Debian “firmware-9.6…” stick and it gets to the
> list of drivers.  I pick e1000e (with is there, along with a bunch of other
> Intel drivers) and go back to see if it now can see the interface.   Nope!
>  It still isn’t seeing the network.
>
>
> What am I missing?  What is Ubuntu doing to make this work that Debian
> doesn’t?
>
>
> Anybody got any suggestions???
>
> Thanks in advance,
> Rick
>
>

Installer can't find network interface on Intel NUC BOXNUC8i3BEH1

[Rick Thomas]

I recently bought an intel NUC BOXNUC8i3BEH1.  You can see a description of the 
product at Newegg:
https://www.newegg.com/Product/Product.aspx?Item=N82E16856102213

I’m trying to install Debian Stretch on it
debian-9.7.0-amd64-DVD-1.iso
and (later)
firmware-9.6.0-amd64-DVD-1.iso

I made a bootable USB stick the usual way with dd to copy the iso to the stick. 
 It boots fine and loads some preliminary stuff.  When it gets to trying to 
identify the network interface, it fails at that task and drops into a screen 
with a long list of network drivers for me to choose from.

I didn’t know what driver to load (the Newegg description says it uses an Intel 
networking chip, but I didn’t know which driver was needed by that chip)  So I 
aborted the installation.  On a hunch, I then tried to install Ubuntu 
(ubuntu-mate-18.04-desktop-amd64.iso) and that works fine.  The network comes 
up automatically.

So, on Ubuntu, I typed “lspci -v” and searched the output for the network 
interface.  It says that the driver installed for that interface is “e1000e”.  
A quick check on a working Stretch system shows that the e1000e driver *is* 
available in Debian.  So, I think to myself, “Problem solved — all I have to do 
is specify the e1000e driver and all will be well!”

Not so fast…  I boot the Debian “firmware-9.6…” stick and it gets to the list 
of drivers.  I pick e1000e (with is there, along with a bunch of other Intel 
drivers) and go back to see if it now can see the interface.   Nope!   It still 
isn’t seeing the network.


What am I missing?  What is Ubuntu doing to make this work that Debian doesn’t?


Anybody got any suggestions???

Thanks in advance,
Rick

Re: Predictable Network Interface Names

[Reco]

Hi.

On Wed, Aug 15, 2018 at 04:46:13PM +0200, Martin wrote:
> Hi ML members,
> 
> I have a bunch of machines, all virtual, where I have to swap the NIC type. 
> Three or four  NIC's per host, e1000 to vmxnet3 for those who may care about.

vmxnet3 is what's important here.

> With Predictable Network Interface Names enabled, it should be possible, to 
> do this automated.

It is now, once they fixed it.

> I got this 'ens' part, no problem. But where do the numbers come from?

Long story short, VMWare NICs were horribly broken in regards to
Predictable Network Interface Names. Since they fixed it RedHat way,
vmxnet3 NICs are called in accordance to ID_NET_NAME_SLOT udev
parameter, see [1].

> It's about that PCI address numbers, right?

It was, but it's not now. Either VMWare was supplying the kernel bogus
PCI address ([1] says that), or systemd upstream misinterpreted that. It
was not predictable back than, but it was nothing that was impossible to
fix (net.ifnames=0, .link files, the usual).

Reco

[1] https://access.redhat.com/solutions/2592561

Predictable Network Interface Names

[Martin]

Hi ML members,

I have a bunch of machines, all virtual, where I have to swap the NIC type. 
Three or four  NIC's per host, e1000 to vmxnet3 for those who may care about. 
With Predictable Network Interface Names enabled, it should be possible, to do 
this automated. Not being lazy, I've read the available documents like from 
Freedesktop.org, and others. What I just do not get is, how do I figure out, 
what name an interface will have before I put them in?
I have a reference system,here it looks like:

[0.901733] vmxnet3 :0b:00.0 eth0: NIC Link is Up 1 Mbps
[0.907950] vmxnet3 :13:00.0 eth1: NIC Link is Up 1 Mbps
[0.917348] vmxnet3 :1b:00.0 eth2: NIC Link is Up 1 Mbps
[0.951209] vmxnet3 :0b:00.0 ens192: renamed from eth0
[0.966569] vmxnet3 :13:00.0 ens224: renamed from eth1
[1.021765] vmxnet3 :1b:00.0 ens256: renamed from eth2

I got this 'ens' part, no problem. But where do the numbers come from? It's 
about that PCI address numbers, right? But I don't see, how this translates.
Push me someone into the right direction, please!

Martin

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

[Patrick Flaig]

Hi Michael,

great, that was the problem, removed the file, recreated the initramfs, now it 
works like a charm.
Thanks a lot for the help.

Patrick

> Am 27.07.2017 um 21:29 schrieb Michael Biebl <bi...@debian.org>:
> 
> Am 27.07.2017 um 20:21 schrieb Patrick Flaig:
>> Sure, this is the content:
>> 
>> cat /tmp/foo/lib/systemd/network/99-default.link 
> 
> Thanks Patrick.
> So, it seems the udev maintainer scripts detected at virtualized
> environment which causes the following code to be triggered:
> 
> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/udev.postinst#n49
> 
> The /etc/systemd/network/99-default.link file overrides the the package
> provided one from /lib/systemd/network/99-default.link
> 
> So, in order to enable the new naming scheme, remove
> /etc/systemd/network/99-default.link then rebuild the initramfs.
> 
> On the next boot you should have the new network interface names.
> 
> Regards,
> Michael
> 
> 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

[Michael Biebl]

Am 27.07.2017 um 20:21 schrieb Patrick Flaig:
> Sure, this is the content:
> 
> cat /tmp/foo/lib/systemd/network/99-default.link 

Thanks Patrick.
So, it seems the udev maintainer scripts detected at virtualized
environment which causes the following code to be triggered:

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/udev.postinst#n49

The /etc/systemd/network/99-default.link file overrides the the package
provided one from /lib/systemd/network/99-default.link

So, in order to enable the new naming scheme, remove
/etc/systemd/network/99-default.link then rebuild the initramfs.

On the next boot you should have the new network interface names.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

[Patrick Flaig]

Sure, this is the content:

cat /tmp/foo/lib/systemd/network/99-default.link 
# This machine is most likely a virtualized guest, where the old persistent
# network interface mechanism (75-persistent-net-generator.rules) did not work.
# This file disables /lib/systemd/network/99-default.link to avoid
# changing network interface names on upgrade. Please read
# /usr/share/doc/udev/README.Debian.gz about how to migrate to the currently
# supported mechanism.

The content of the README, doesn’t help that much as 99-default.link doesn’t 
seem to be a symlink.

cat /usr/share/doc/udev/README.Debian 
This documents udev integration Debian specifics. Please see man udev(7) and
its referenced manpages for general documentation.

Network interface naming

Since version 197 udev has a builtin persistent name generator which checks
firmware/BIOS provided index numbers or slot names (similar to biosdevname),
falls back to slot names (PCI numbers, etc., in the spirit of
/dev/disks/by-path/), and then optionally falls back to MAC address, and
generates names based on these properties. This provides "location oriented"
names for PCI cards such as "enp0s1" for ethernet, or wlp1s0" for a WIFI card
so that replacing a broken network card does not change the name. As location
based naming does not work well for USB devices, these use a MAC based naming
schema (see /lib/udev/rules.d/73-usb-net-by-mac.rules).

This has been enabled by default since udev 220-7, which affects new
installations/hardware. Existing installations/hardware which already got
covered by the old 75-persistent-net-generator.rules will keep their interface
names, see below.

You can disable these stable names and go back to the kernel-provided ones
(which don't have a stable order) in one of two ways:

  - Put "net.ifnames=0" into the kernel command line (e. g. in
/etc/default/grub's GRUB_CMDLINE_LINUX_DEFAULT, then run "update-grub").

  - Disable the default *.link rules with
"ln -s /dev/null /etc/systemd/network/99-default.link"
and rebuild the initrd with "update-initramfs -u".

See this page for more information:
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Legacy persistent network interface naming
~~
Debian releases up to 8 ("Jessie") and Ubuntu up to 15.04 had an udev rule
/lib/udev/rules.d/75-persistent-net-generator.rules which fixed the name of a
network interface that it got when its MAC address first appeared in a
dynamically created /etc/udev/rules.d/70-persistent-net.rules file.

This had inherent race conditions (which sometimes caused collisions and
interface names like "rename1"), required having to write state into /etc
(which isn't possible for read-only root), and did not work in virtualized
environments.

This old schema is deprecated in Debian 9 ("Stretch"), and will not
be supported any more in Debian 10.

Migration to the current network interface naming
~
On package upgrade systems will keep their current names, but they will need to
be manually migrated by Debian 10 / Ubuntu 18.04 LTS.  If you rely on the old
names in custom ifupdown stanzas, firewall scripts or other networking
configuration, these need to be updated to the new names.

First, determine all relevant network interface names: those in
/etc/udev/rules.d/70-persistent-net.rules, or if that does not exist (in
virtual machines), in "ip link" or /sys/class/net/.

Then for every interface name use a command like

  grep -r eth0 /etc

to find out where it is being used.

Then on "real hardware" machines, rename the file to
70-persistent-net.rules.old; on VMs remove the file
/etc/udev/rules.d/80-net-setup-link.rules instead.

Reboot, adjust configuration files, and test your system.

Custom net interface naming
~~~
In some cases it is convenient to define your own specific names for network
interfaces. These can be customized in two different ways:

 * You can create your own names via udev rules, based on arbitrary attribute
   and property matches. See man udev(7) for documentation how to write udev
   rules. For example, you can create /etc/udev/rules.d/76-netnames.rules with

    snip --
   # identify device by MAC address
   SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="11:22:aa:bb:cc:33", 
NAME="eth-dmz"

   # identify by vendor/model ID
   SUBSYSTEM=="net", ACTION=="add", ENV{ID_VENDOR_ID}=="0x8086", \
   ENV{ID_MODEL_ID}=="0x1502", NAME="eth-intel-gb"

   # USB device by path
   # get ID_PATH if not present yet
   ENV{ID_PATH}=="", IMPORT{builtin}="path_id"
   SUBSYSTEM=="net", ACTION=="add", ENV{ID_PATH}==&quo

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

[Michael Biebl]

Am 27.07.2017 um 19:50 schrieb Patrick Flaig:
> Oh my fault, 99-default.link is available, I checked the wrong folder.
> The file is containing some text, saying that the machine is most likely a 
> virtualized guest.

Can you paste the contents verbatim.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

[Patrick Flaig]

Oh my fault, 99-default.link is available, I checked the wrong folder.
The file is containing some text, saying that the machine is most likely a 
virtualized guest.

> Am 27.07.2017 um 19:28 schrieb Michael Biebl :
> 
> Am 27.07.2017 um 18:55 schrieb debian-li...@patschie.de:
> 
>>> Am 27.07.2017 um 18:25 schrieb Michael Biebl :
>>> lsinitramfs /boot/initrd.img-$(uname -r) | grep 99-default.link
>>> lib/systemd/network/99-default.link
>> Missing
> 
> Odd. Do you have that file on the host system?
> Can you check with debsums -as udev systemd.
> 
> /usr/share/initramfs-tools/hooks/udev should copy that link file into
> the initramfs.
> 
> Do you by chance have any custom initramfs hooks in
> /etc/initramfs-tools/hooks which override the udev hook?
> 
> 

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

[Michael Biebl]

Am 27.07.2017 um 18:55 schrieb debian-li...@patschie.de:

>> Am 27.07.2017 um 18:25 schrieb Michael Biebl :
>> lsinitramfs /boot/initrd.img-$(uname -r) | grep 99-default.link
>> lib/systemd/network/99-default.link
> Missing

Odd. Do you have that file on the host system?
Can you check with debsums -as udev systemd.

/usr/share/initramfs-tools/hooks/udev should copy that link file into
the initramfs.

Do you by chance have any custom initramfs hooks in
/etc/initramfs-tools/hooks which override the udev hook?




signature.asc
Description: OpenPGP digital signature

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

[debian-lists]

> Am 27.07.2017 um 18:25 schrieb Michael Biebl :
> 
> Am 27.07.2017 um 18:04 schrieb debian-li...@patschie.de:
>> Hi Michael,
>> 
>> I forgot to mention that I also recreated the initramfs: 
>> after several tries just to update it, I deleted the initramfs and recreated 
>> it completely.
>> But still the same effect.
>> 
>> Is there a way to manually check the contents of the initramfs, just to make 
>> sure that the 70-persistent-net.rules isn’t there?
> 
> 
> lsinitramfs /boot/initrd.img-$(uname -r) | grep  70-persistent-net.rules
> 
> This should come up empty.
Confirmed
> 
> The new naming is setup via /lib/udev/rules.d/80-net-setup-link.rules
> and a link file called  99-default.link
99-default.link is missing
> 
> lsinitramfs /boot/initrd.img-$(uname -r) | grep  80-net-setup-link.rules
> lib/udev/rules.d/80-net-setup-link.rules
Available
> lsinitramfs /boot/initrd.img-$(uname -r) | grep 99-default.link
> lib/systemd/network/99-default.link
Missing
> 
> Is this a bare metal or a VM?
VirtualBox VM, as well as the Stretch clean install system, where the 
predictable names are working fine. 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

[Patrick Flaig]

> Am 27.07.2017 um 18:25 schrieb Michael Biebl :
> 
> Am 27.07.2017 um 18:04 schrieb debian-li...@patschie.de:
>> Hi Michael,
>> 
>> I forgot to mention that I also recreated the initramfs: 
>> after several tries just to update it, I deleted the initramfs and recreated 
>> it completely.
>> But still the same effect.
>> 
>> Is there a way to manually check the contents of the initramfs, just to make 
>> sure that the 70-persistent-net.rules isn’t there?
> 
> 
> lsinitramfs /boot/initrd.img-$(uname -r) | grep  70-persistent-net.rules
> 
> This should come up empty.
Confirmed
> 
> The new naming is setup via /lib/udev/rules.d/80-net-setup-link.rules
> and a link file called  99-default.link
99-default.link is missing
> 
> lsinitramfs /boot/initrd.img-$(uname -r) | grep  80-net-setup-link.rules
> lib/udev/rules.d/80-net-setup-link.rules
Available
> lsinitramfs /boot/initrd.img-$(uname -r) | grep 99-default.link
> lib/systemd/network/99-default.link
Missing
> 
> Is this a bare metal or a VM?
VirtualBox VM, as well as the Stretch clean install system, where the 
predictable names are working fine. 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

[Patrick Flaig]

Thanks,

confirmed, the initrd doesn’t contain any udev rule files in /etc/udev/rules.d
 
> Am 27.07.2017 um 18:11 schrieb Greg Wooledge :
> 
> On Thu, Jul 27, 2017 at 06:04:49PM +0200, debian-li...@patschie.de wrote:
>> Is there a way to manually check the contents of the initramfs, just to make 
>> sure that the 70-persistent-net.rules isn’t there?
> 
> mkdir /tmp/foo &&
> cd /tmp/foo &&
> unmkinitramfs /boot/initrd.whatever
> 
> (The old way of just running cpio won't work any more, because the new
> initrd.img files are a concatenation of multiple cpio archives.)
> 

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

[Michael Biebl]

Am 27.07.2017 um 18:04 schrieb debian-li...@patschie.de:
> Hi Michael,
> 
> I forgot to mention that I also recreated the initramfs: 
> after several tries just to update it, I deleted the initramfs and recreated 
> it completely.
> But still the same effect.
> 
> Is there a way to manually check the contents of the initramfs, just to make 
> sure that the 70-persistent-net.rules isn’t there?


lsinitramfs /boot/initrd.img-$(uname -r) | grep  70-persistent-net.rules

This should come up empty.

The new naming is setup via /lib/udev/rules.d/80-net-setup-link.rules
and a link file called  99-default.link

lsinitramfs /boot/initrd.img-$(uname -r) | grep  80-net-setup-link.rules
lib/udev/rules.d/80-net-setup-link.rules
lsinitramfs /boot/initrd.img-$(uname -r) | grep 99-default.link
lib/systemd/network/99-default.link

Is this a bare metal or a VM?
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

[Greg Wooledge]

On Thu, Jul 27, 2017 at 06:04:49PM +0200, debian-li...@patschie.de wrote:
> Is there a way to manually check the contents of the initramfs, just to make 
> sure that the 70-persistent-net.rules isn’t there?

mkdir /tmp/foo &&
cd /tmp/foo &&
unmkinitramfs /boot/initrd.whatever

(The old way of just running cpio won't work any more, because the new
initrd.img files are a concatenation of multiple cpio archives.)

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

[debian-lists]

Hi Michael,

I forgot to mention that I also recreated the initramfs: 
after several tries just to update it, I deleted the initramfs and recreated it 
completely.
But still the same effect.

Is there a way to manually check the contents of the initramfs, just to make 
sure that the 70-persistent-net.rules isn’t there?

Patrick

> Am 27.07.2017 um 17:57 schrieb Michael Biebl <bi...@debian.org>:
> 
> Hi Patrick
> 
> Am 27.07.2017 um 17:15 schrieb debian-li...@patschie.de:
>> Hi,
>> 
>> I’m running into some troubles to enable the predictable network interface 
>> names for a system upgraded from Jessie.
>> 
>> What I figured out so far:
>> Setting net.ifnames=1 on the kernel command line doesn’t help and seems no 
>> longer to be supported parameter (at least "sysctl - a" doesn’t show it).
> 
> Setting that parameter should work, but it doesn't take precedence over
> an existing /etc/udev/rules.d/70-persistent-net.rules
> 
> Since net.ifnames=1 is the default since stretch, you don't need to set
> it explicitly though.
> 
>> Removing any /etc/udev/rules.d/ file handling the network interface doesn’t 
>> bring the desired effect of having predictable network interface names.
>> 
>> I started now to compare /lib/udev/rules.d from a clean stretch installation 
>> with the files on a upgraded system, the clean installation has much more 
>> files.
>> So next try reinstalling udev to get all missing/new rule files from 
>> stretch, but that didn’t work either.
>> 
>> Any ideas what I could try next or missed to check?
>> 
> 
> Most likely the file /etc/udev/rules.d/70-persistent-net.rules got
> embedded in the initramfs. So once you removed that file, you also need
> to rebuild the initramfs via update-initramfs -u
> 
> Michael
> 

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

[Michael Biebl]

Hi Patrick

Am 27.07.2017 um 17:15 schrieb debian-li...@patschie.de:
> Hi,
> 
> I’m running into some troubles to enable the predictable network interface 
> names for a system upgraded from Jessie.
> 
> What I figured out so far:
> Setting net.ifnames=1 on the kernel command line doesn’t help and seems no 
> longer to be supported parameter (at least "sysctl - a" doesn’t show it).

Setting that parameter should work, but it doesn't take precedence over
an existing /etc/udev/rules.d/70-persistent-net.rules

Since net.ifnames=1 is the default since stretch, you don't need to set
it explicitly though.

> Removing any /etc/udev/rules.d/ file handling the network interface doesn’t 
> bring the desired effect of having predictable network interface names.
> 
> I started now to compare /lib/udev/rules.d from a clean stretch installation 
> with the files on a upgraded system, the clean installation has much more 
> files.
> So next try reinstalling udev to get all missing/new rule files from stretch, 
> but that didn’t work either.
> 
> Any ideas what I could try next or missed to check?
> 

Most likely the file /etc/udev/rules.d/70-persistent-net.rules got
embedded in the initramfs. So once you removed that file, you also need
to rebuild the initramfs via update-initramfs -u

Michael



signature.asc
Description: OpenPGP digital signature

Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

[debian-lists]

Hi,

I’m running into some troubles to enable the predictable network interface 
names for a system upgraded from Jessie.

What I figured out so far:
Setting net.ifnames=1 on the kernel command line doesn’t help and seems no 
longer to be supported parameter (at least "sysctl - a" doesn’t show it).
Removing any /etc/udev/rules.d/ file handling the network interface doesn’t 
bring the desired effect of having predictable network interface names.

I started now to compare /lib/udev/rules.d from a clean stretch installation 
with the files on a upgraded system, the clean installation has much more files.
So next try reinstalling udev to get all missing/new rule files from stretch, 
but that didn’t work either.

Any ideas what I could try next or missed to check?

Thanks a lot.

Patrick

Re: Predictable Network Interface Names prevents WiFi connections.

[Marcos Raúl Carot]

Hi Miguel,

Did you ever get an answer about this?

I can't get Network Manager (from KDE) to connect if the predictable
network interface names are enabled.

Cheers,

Marcos

Re: how to compute predictable network interface names?

[Harald Dunkel]

Hi Christian,

On 02/24/17 12:43, Christian Seiler wrote:
> 
> udev will then rename the device once it encounters it.
> 
> In newer udev versions, it will use some (but not all) settings from
> systemd.link files. The other settings are interpreted by
> systemd.networkd. (And if you don't use that or don't have that
> installed, they will be ignored.) That's also the reasnon why those
> files are in a systemd directory, even though udev interprets some
> parts of them - since the matching of interfaces is identical for
> the purposes of udev and systemd-networkd, systemd developers decided
> it would be simpler to have just one configuration file that is read
> by both. (udev and systemd are both in the same repository, even
> though you can use udev without systemd.)
> 

Thats a bad choice. Now the man page is not installed on
"udev-only" systems, because the package maintainer recognized
it as a "systemd" man page. #857270

> 
> No. net.ifnames=0 will have udev completely ignore NamePolicy here
> and not rename the interface at all.
> 

Is there a policy option telling udev/systemd to not touch the
interface names? AFAIU that should be easy to implement, but
there is no "NamePolicy=keep" described in systemd.link(5) (or
I was too blind to see).


Regards
Harri

Re: how to compute predictable network interface names?

[Christian Seiler]

On 02/24/2017 10:10 AM, Harald Dunkel wrote:
> On 02/23/2017 04:25 PM, Christian Seiler wrote:
>>
>> There's a policy which are going to be preferred. man 5 systemd.link
>> tells you what the options are and /lib/systemd/network/99-default.link
>> tells you what the default setting is (the first successful one is
>> used).
> 
> Of course I stumbled over this one:
> 
> % man 5 systemd.link
> No manual entry for systemd.link in section 5
> 
> Now I got confused: Who is responsible for renaming the NIC names?
> Is this a systemd feature, is this the job of udev, or are the NICs
> renamed by the kernel very early at boot time? Shouldn't I get the
> same predictable name for eth0, no matter what?

udev is responsible.

The kernel drivers give the NIC a name initially, and they can mark
that name as being "persistent" or not. The vast majority of drivers
do not mark the name as being persistent.

The names the kernel returns will typically be something like eth0,
etc.

udev will then rename the device once it encounters it.

In newer udev versions, it will use some (but not all) settings from
systemd.link files. The other settings are interpreted by
systemd.networkd. (And if you don't use that or don't have that
installed, they will be ignored.) That's also the reasnon why those
files are in a systemd directory, even though udev interprets some
parts of them - since the matching of interfaces is identical for
the purposes of udev and systemd-networkd, systemd developers decided
it would be simpler to have just one configuration file that is read
by both. (udev and systemd are both in the same repository, even
though you can use udev without systemd.)

>> On my Stretch system that is:
>>
>> NamePolicy=kernel database onboard slot path
>>
> 
> AFAIU
>   NamePolicy=kernel
> 
> makes sure that net.ifnames=0 given on the kernel command line
> works. Is this correct?

No. net.ifnames=0 will have udev completely ignore NamePolicy here
and not rename the interface at all.

NamePolicy=kernel will most likely never trigger on any system you
have (it has never triggered on any system I have), it's for the
case where the kernel driver says "yeah, the name I chose is already
a name that's going to be persistent". This will never be interfaces
like eth0, etc. I suspect this is mostly for SoC-type devices which
have one onboard network interface that's fixed and thus will always
have the same name.

>> 'kernel' and 'database' are likely going to fail in most cases (kernel
>> means the kernel indicates that the name used so far is already
>> predictable, which it only does for very special hardware, probably
>> embedded or similar, and database means that there's an entry in the
>> udev hardware database, which you'd have to do manually, because I
>> don't know of any upstream rules), so basically it's the following
>> logic:
>>
>>  - first try ID_NET_NAME_ONBOARD
>>  - if that doesn't exist, try ID_NET_NAME_SLOT 
>>  - if that doesn't exist, try ID_NET_NAME_PATH
>>
> Not to forget
> 
> - if that doesn't exist, use INTERFACE

>From the code logic, sure, but you'll be hard-pressed to find an
interface that doesn't have ID_NET_NAME_PATH set. ;-)

Regards,
Christian

Re: how to compute predictable network interface names?

[Harald Dunkel]

On 02/24/2017 10:10 AM, Harald Dunkel wrote:
> 
> Now I got confused: Who is responsible for renaming the NIC names?
> Is this a systemd feature, is this the job of udev, or are the NICs
> renamed by the kernel very early at boot time? Shouldn't I get the
> same predictable name for eth0, no matter what?
> 
PS: Assuming the hardware isn't changed, of course.

Harri

Re: how to compute predictable network interface names?

[Harald Dunkel]

On 02/23/2017 04:25 PM, Christian Seiler wrote:
> 
> There's a policy which are going to be preferred. man 5 systemd.link
> tells you what the options are and /lib/systemd/network/99-default.link
> tells you what the default setting is (the first successful one is
> used).

Of course I stumbled over this one:

% man 5 systemd.link
No manual entry for systemd.link in section 5

Now I got confused: Who is responsible for renaming the NIC names?
Is this a systemd feature, is this the job of udev, or are the NICs
renamed by the kernel very early at boot time? Shouldn't I get the
same predictable name for eth0, no matter what?

> On my Stretch system that is:
> 
> NamePolicy=kernel database onboard slot path
> 

AFAIU
NamePolicy=kernel

makes sure that net.ifnames=0 given on the kernel command line
works. Is this correct?

> 'kernel' and 'database' are likely going to fail in most cases (kernel
> means the kernel indicates that the name used so far is already
> predictable, which it only does for very special hardware, probably
> embedded or similar, and database means that there's an entry in the
> udev hardware database, which you'd have to do manually, because I
> don't know of any upstream rules), so basically it's the following
> logic:
> 
>  - first try ID_NET_NAME_ONBOARD
>  - if that doesn't exist, try ID_NET_NAME_SLOT 
>  - if that doesn't exist, try ID_NET_NAME_PATH
> 
Not to forget

- if that doesn't exist, use INTERFACE


Thanx very much for your detailed response.

Harri

Re: how to compute predictable network interface names?

[Stephen Powell]

On Thu, Feb 23, 2017, at 10:16, Harald Dunkel wrote:
> On 02/16/2017 12:47 PM, Christian Seiler wrote:
> > 
> > On a system with predictable names running? Or on a system
> > pre-upgrade?
> > 
> 
> Its more "pre-installation". I boot a USB stick and run
> my own installer (using debootstrap or creating a clone).
> The NIC name is needed to setup /etc/network/interfaces.
> I know how the interfaces are named using the old scheme,
> but the predictable names are hard to guess.
> 

Debian used to assign network devices based on MAC address.
If you want to continue doing something like that, use the
kernel boot parameter

   net.ifnames=0

and create your own udev rule.  For example:

   /etc/udev/rules.d/76-netnames.rules:

   # Create custom network interface names based on MAC address.
   SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:11:25:86:61:87", 
NAME="net0"

This rule will assign the Ethernet adapter with MAC address 00:11:25:86:61:87
the interface name net0.  Reference the interface by this name in
/etc/network/interfaces.

I hope this helps.

-- 
  .''`. Stephen Powell<zlinux...@fastmail.com>
 : :'  :
 `. `'`
   `-

Re: how to compute predictable network interface names?

[Christian Seiler]

On 02/23/2017 04:16 PM, Harald Dunkel wrote:
> On 02/16/2017 12:47 PM, Christian Seiler wrote:
>>
>> On a system with predictable names running? Or on a system
>> pre-upgrade?
>>
> 
> Its more "pre-installation". I boot a USB stick and run
> my own installer (using debootstrap or creating a clone).
> The NIC name is needed to setup /etc/network/interfaces.
> I know how the interfaces are named using the old scheme,
> but the predictable names are hard to guess.
> 
>> Because if you have a system that's being upgraded at the
>> moment, the following command _might_ work _after_ you've
>> upgraded udev and _before_ you've rebooted the system.
>>
>> udevadm info /sys/class/net/eth4
>>
>> Look at ID_NET_NAME there.
>>
> 
> I found 3 for eth0 on my desktop PC:
> 
>   E: ID_NET_NAME_MAC=enx54bef70930bd
>   E: ID_NET_NAME_ONBOARD=eno1
>   E: ID_NET_NAME_PATH=enp0s25
> 
> For a server with 6 NICs I got for eth4
> 
>   E: ID_NET_NAME_MAC=enx0cc47a860566
>   E: ID_NET_NAME_PATH=enp4s0f2
>   E: ID_NET_NAME_SLOT=ens261f2
> 
> A wild guess would be it is "ID_NET_NAME_PATH" unless there is
> a "ID_NET_NAME_ONBOARD" ? I understand that this is the fragile
> part.

There's a policy which are going to be preferred. man 5 systemd.link
tells you what the options are and /lib/systemd/network/99-default.link
tells you what the default setting is (the first successful one is
used). On my Stretch system that is:

NamePolicy=kernel database onboard slot path

'kernel' and 'database' are likely going to fail in most cases (kernel
means the kernel indicates that the name used so far is already
predictable, which it only does for very special hardware, probably
embedded or similar, and database means that there's an entry in the
udev hardware database, which you'd have to do manually, because I
don't know of any upstream rules), so basically it's the following
logic:

 - first try ID_NET_NAME_ONBOARD
 - if that doesn't exist, try ID_NET_NAME_SLOT 
 - if that doesn't exist, try ID_NET_NAME_PATH

Regards,
Christian

Re: how to compute predictable network interface names?

[Harald Dunkel]

On 02/16/2017 12:47 PM, Christian Seiler wrote:
> 
> On a system with predictable names running? Or on a system
> pre-upgrade?
> 

Its more "pre-installation". I boot a USB stick and run
my own installer (using debootstrap or creating a clone).
The NIC name is needed to setup /etc/network/interfaces.
I know how the interfaces are named using the old scheme,
but the predictable names are hard to guess.

> Because if you have a system that's being upgraded at the
> moment, the following command _might_ work _after_ you've
> upgraded udev and _before_ you've rebooted the system.
> 
> udevadm info /sys/class/net/eth4
> 
> Look at ID_NET_NAME there.
> 

I found 3 for eth0 on my desktop PC:

E: ID_NET_NAME_MAC=enx54bef70930bd
E: ID_NET_NAME_ONBOARD=eno1
E: ID_NET_NAME_PATH=enp0s25

For a server with 6 NICs I got for eth4

E: ID_NET_NAME_MAC=enx0cc47a860566
E: ID_NET_NAME_PATH=enp4s0f2
E: ID_NET_NAME_SLOT=ens261f2

A wild guess would be it is "ID_NET_NAME_PATH" unless there is
a "ID_NET_NAME_ONBOARD" ? I understand that this is the fragile
part.


Nice tip, thanx very much
Harri

Re: how to compute predictable network interface names?

[Greg Wooledge]

On Thu, Feb 16, 2017 at 12:47:25PM +0100, Christian Seiler wrote:
> On a system with predictable names running? Or on a system
> pre-upgrade?
> 
> Because if you have a system that's being upgraded at the
> moment, the following command _might_ work _after_ you've
> upgraded udev and _before_ you've rebooted the system.
> 
> udevadm info /sys/class/net/eth4
> 
> Look at ID_NET_NAME there.
> 
> Can't really test that though, since I don't have a setup
> with the old scheme that I still need to upgrade, so this
> might not work at all.

I'm a bit confused here.  On a system that's upgraded from jessie to
stretch, why would the interface names change at all?  The old eth0
style names are recorded in /etc/udev/rules.d/70-persistent-net.rules
and the interfaces continue to come up as eth0, etc.

Are you talking about a scenario where you upgrade to stretch and then
add a new NIC?  But even then it still wouldn't make sense, because
you wouldn't have had a previous "eth4" name that you want to map to a
new name.  You'd just get the new name.

Or are you talking about a hypothetical scenario where you upgrade to
stretch and then remove the contents of
/etc/udev/rules.d/70-persistent-net.rules, but before you do that, you
want to see what the interfaces will become?  That seems... quite odd
to me.  Why not just leave the interfaces alone?

Re: how to compute predictable network interface names?

[Christian Seiler]

On 02/16/2017 12:24 PM, Harald Dunkel wrote:
> I understand that the predictable nic names can be turned off
> using
> 
>   net.ifnames=0
> 
> on the kernel command line, but I wonder if there is a shell
> script to actually predict the "enpYsZ" from the old style
> "ethX" initially assigned by the kernel? Something like
> 
>   % predict_nic eth4
>   enp12s1

On a system with predictable names running? Or on a system
pre-upgrade?

Because if you have a system that's being upgraded at the
moment, the following command _might_ work _after_ you've
upgraded udev and _before_ you've rebooted the system.

udevadm info /sys/class/net/eth4

Look at ID_NET_NAME there.

Can't really test that though, since I don't have a setup
with the old scheme that I still need to upgrade, so this
might not work at all.

If your system has already switched to the new scheme,
then 'eth4' is meaningless once the devices have been
renamed, so you don't really know.

Also, the reason why the new scheme was introduced is that
on some systems ethX is not reproducible: the order in
which the devices are found by the kernel can change
(especially if you have USB devices, but also in other
cases) so 'eth4' is often ambivalent anyway.

If you have some other information on identifying the
device (such as the device's MAC address), you can identify
it that way by looking for the interface with that MAC and
name it something yourself.

For example, you could create a file [1]
/etc/systemd/network/10-uplink.link
with the following contents:

[Match]
MACAddress=xx:yy:zz:gg:hh:ii

[Link]
Name=uplink

This way the network interface with the specified MAC
address is now called "uplink" instead of "enp12s1" or
whatever it was previously. You can also match by PCI
paths (udevadm info's ID_PATH attribute) and matching
supports wildcards. See the manpage for systemd.link
for further details.

Regards,
Christian

[1] This works even on non-systemd systems with udev because
*.link files are interpreted by udev's builtin and _not_
by systemd, so technically the location is a bit
misleading.

how to compute predictable network interface names?

[Harald Dunkel]

Hi folks,

I understand that the predictable nic names can be turned off
using

net.ifnames=0

on the kernel command line, but I wonder if there is a shell
script to actually predict the "enpYsZ" from the old style
"ethX" initially assigned by the kernel? Something like

% predict_nic eth4
enp12s1

There are some recipes I found on the net, but they all appear
questionable or "this_vendor systems only" or work only for
X=0 or look just like some attempt to start yet another flame
war.

Parsing dmesg output seems to be the most stable solution I
found by now.


Every helpful comment is highly appreciated.

Regards
Harri

Predictable Network Interface Names prevents WiFi connections.

[Miguel A. Vallejo]

Hello. I'm having a weird problem with my Debian testing installation. I
use KDE Plasma 5 and NetworkManager in a up-to-date system.

The problem is I can't connect to any wifi if Predictable Network Interface
Names are in use.

I can see all wireless networks in Network Manager, so I select mine, I
enter the network password and I can see this in syslog


Dec  6 14:47:31 waterhole NetworkManager[562]:   [1481032051.7586]
keyfile: add connection in-memory
(7c83331f-74b7-4ef8-98a5-67bc03e24b36,"EOZWireless2")
Dec  6 14:47:31 waterhole NetworkManager[562]:   [1481032051.7954]
device (wlx1c7ee55ecc0a): Activation: starting connection 'EOZWireless2'
(7c83331f-74b7-4ef8-98a5-67bc03e24b36)
Dec  6 14:47:31 waterhole NetworkManager[562]:   [1481032051.8158]
keyfile: update /etc/NetworkManager/system-connections/EOZWireless2
(7c83331f-74b7-4ef8-98a5-67bc03e24b36,"EOZWireless2") and persist connection
Dec  6 14:47:31 waterhole NetworkManager[562]:   [1481032051.8160]
audit: op="connection-add-activate"
uuid="7c83331f-74b7-4ef8-98a5-67bc03e24b36" name="EOZWireless2" pid=1137
uid=1000 result="success"
Dec  6 14:47:31 waterhole NetworkManager[562]:   [1481032051.8213]
device (wlx1c7ee55ecc0a): state change: disconnected -> prepare (reason
'none') [30 40 0]
Dec  6 14:47:31 waterhole NetworkManager[562]:   [1481032051.8221]
manager: NetworkManager state is now CONNECTING
Dec  6 14:47:31 waterhole NetworkManager[562]:   [1481032051.8611]
device (wlx1c7ee55ecc0a): set-hw-addr: set-cloned MAC address to
1C:7E:E5:5E:CC:0A (permanent)
Dec  6 14:47:32 waterhole kernel: [  205.121018] IPv6: ADDRCONF(NETDEV_UP):
wlx1c7ee55ecc0a: link is not ready
Dec  6 14:47:32 waterhole NetworkManager[562]:   [1481032052.0483]
device (wlx1c7ee55ecc0a): state change: prepare -> config (reason 'none')
[40 50 0]
Dec  6 14:47:32 waterhole NetworkManager[562]:   [1481032052.0494]
device (wlx1c7ee55ecc0a): Activation: (wifi) access point 'EOZWireless2'
has security, but secrets are required.
Dec  6 14:47:32 waterhole NetworkManager[562]:   [1481032052.0505]
device (wlx1c7ee55ecc0a): state change: config -> need-auth (reason 'none')
[50 60 0]
Dec  6 14:47:32 waterhole NetworkManager[562]:   [1481032052.0575]
device (wlx1c7ee55ecc0a): state change: need-auth -> prepare (reason
'none') [60 40 0]
Dec  6 14:47:32 waterhole NetworkManager[562]:   [1481032052.0585]
device (wlx1c7ee55ecc0a): state change: prepare -> config (reason 'none')
[40 50 0]
Dec  6 14:47:32 waterhole NetworkManager[562]:   [1481032052.0592]
device (wlx1c7ee55ecc0a): Activation: (wifi) connection 'EOZWireless2' has
security, and secrets exist.  No new secrets needed.
Dec  6 14:47:32 waterhole NetworkManager[562]:   [1481032052.0598]
Config: added 'ssid' value 'EOZWireless2'
Dec  6 14:47:32 waterhole NetworkManager[562]:   [1481032052.0602]
Config: added 'scan_ssid' value '1'
Dec  6 14:47:32 waterhole NetworkManager[562]:   [1481032052.0605]
Config: added 'key_mgmt' value 'WPA-PSK'
Dec  6 14:47:32 waterhole NetworkManager[562]:   [1481032052.0605]
Config: added 'auth_alg' value 'OPEN'
Dec  6 14:47:32 waterhole NetworkManager[562]:   [1481032052.0605]
Config: added 'psk' value ''
Dec  6 14:47:32 waterhole NetworkManager[562]:   [1481032052.0625]
sup-iface[0x55680e8fe970,wlx1c7ee55ecc0a]: config: set interface ap_scan to
1
Dec  6 14:47:32 waterhole NetworkManager[562]:   [1481032052.0976]
device (wlx1c7ee55ecc0a): supplicant interface state: inactive -> scanning
Dec  6 14:47:36 waterhole wpa_supplicant[614]: wlx1c7ee55ecc0a: SME: Trying
to authenticate with 4c:60:de:6b:c3:0c (SSID='EOZWireless2' freq=5200 MHz)
Dec  6 14:47:36 waterhole kernel: [  209.921607] wlx1c7ee55ecc0a:
authenticate with 4c:60:de:6b:c3:0c
Dec  6 14:47:36 waterhole kernel: [  210.000312] wlx1c7ee55ecc0a: send auth
to 4c:60:de:6b:c3:0c (try 1/3)
Dec  6 14:47:36 waterhole kernel: [  210.001329] wlx1c7ee55ecc0a:
authenticated
Dec  6 14:47:36 waterhole NetworkManager[562]:   [1481032056.9302]
device (wlx1c7ee55ecc0a): supplicant interface state: scanning ->
authenticating
Dec  6 14:47:41 waterhole wpa_supplicant[614]: wlx1c7ee55ecc0a: SME: Deauth
request to the driver failed
Dec  6 14:47:41 waterhole NetworkManager[562]:   [1481032061.9310]
device (wlx1c7ee55ecc0a): supplicant interface state: authenticating ->
disconnected
Dec  6 14:47:42 waterhole NetworkManager[562]:   [1481032062.0313]
device (wlx1c7ee55ecc0a): supplicant interface state: disconnected ->
scanning
Dec  6 14:47:46 waterhole wpa_supplicant[614]: wlx1c7ee55ecc0a: SME: Trying
to authenticate with 4c:60:de:6b:c3:0c (SSID='EOZWireless2' freq=5200 MHz)
Dec  6 14:47:46 waterhole kernel: [  219.838794] wlx1c7ee55ecc0a:
authenticate with 4c:60:de:6b:c3:0c
Dec  6 14:47:46 waterhole kernel: [  219.916673] wlx1c7ee55ecc0a: send auth
to 4c:60:de:6b:c3:0c (try 1/3)
Dec  6 14:47:46 waterhole NetworkManager[562]:   [1481032066.8465]
device (wlx1c7ee55ecc0a): supplicant inte

Re: Huawei E173 - no more network interface?

[Kamil Jońca]

kjo...@poczta.onet.pl (Kamil Jońca) writes:

> Sometimes[1] I had to use Huawei E173 gsm modem.
> About a year ago, when I put this modem in USB port I got network
> interface like wwan0 or usb0.
> But now this not happen any more.
> I got only ttyUSB? interfaces.

It is considered rude to answer myself, but  it turned out, that modem
were at strange state and presented to system as
12d1:1001 instead 12d1:1446 [1]

sending

--8<---cut here---start->8---
AT^U2DIAG=256
ATZ
--8<---cut here---end--->8---
to ttyUSB0 resovlved my issue


KJ
[1] - vendorID:productId

-- 
http://wolnelektury.pl/wesprzyj/teraz/
Stop ahead.

Huawei E173 - no more network interface?

[Kamil Jońca]

Sometimes[1] I had to use Huawei E173 gsm modem.
About a year ago, when I put this modem in USB port I got network
interface like wwan0 or usb0.
But now this not happen any more.
I got only ttyUSB? interfaces.
What should I check/do to have network interface?
KJ

-- 
http://wolnelektury.pl/wesprzyj/teraz/
Kent's Heuristic:
Look for it first where you'd most like to find it.

Re: LSB Raise network interface taking too long

[Michael Biebl]

Am 27.03.2015 um 17:07 schrieb Paulo Roberto:
 Hello,
 
 During the boot, when it's time to bring the interfaces up, this process
 takes more than 5 minutes.
 The below message is displayed on the screen:
 
 A start job is running for LSB: Raise network interface [5:16]
 
 After the timeout the systems works normally.
 
 I'm using Lenny on a 64bit machine and the systemd init system.

I assume you mean Jessie here.

  It seams the problem is some race condition that results in a deadlock.
 The systemd is waiting for a condition that never is satisfied.

..

 Mar 27 09:50:36 vali networking[745]: run-parts: executing
 /etc/network/if-up.d/openntpd

I think the problem is the openntpd hook, which calls
invoke-rc.d openntpd force-reload.

/etc/init.d/openntpd itself requires $network though.
So this might be the dead lock.

If you purge openntpd, or remove /etc/network/if-up.d/openntpd, is the
problem gone?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: LSB Raise network interface taking too long

[Paulo Roberto]

Michael,

Yes, I mean Jessie. Sorry.

And you were right, removing the /etc/network/if-up.d/openntpd the problem
was gone.

I assume that this file that comes in the openntpd package should not exist.
Am I correct?

Thanks a lot for your help.

Kind Regards.



On Fri, Mar 27, 2015 at 2:14 PM, Michael Biebl bi...@debian.org wrote:

 Am 27.03.2015 um 17:07 schrieb Paulo Roberto:
  Hello,
 
  During the boot, when it's time to bring the interfaces up, this process
  takes more than 5 minutes.
  The below message is displayed on the screen:
 
  A start job is running for LSB: Raise network interface [5:16]
 
  After the timeout the systems works normally.
 
  I'm using Lenny on a 64bit machine and the systemd init system.

 I assume you mean Jessie here.

   It seams the problem is some race condition that results in a deadlock.
  The systemd is waiting for a condition that never is satisfied.

 ..

  Mar 27 09:50:36 vali networking[745]: run-parts: executing
  /etc/network/if-up.d/openntpd

 I think the problem is the openntpd hook, which calls
 invoke-rc.d openntpd force-reload.

 /etc/init.d/openntpd itself requires $network though.
 So this might be the dead lock.

 If you purge openntpd, or remove /etc/network/if-up.d/openntpd, is the
 problem gone?


 --
 Why is it that all of the instruments seeking intelligent life in the
 universe are pointed away from Earth?

LSB Raise network interface taking too long

[Paulo Roberto]

Hello,

During the boot, when it's time to bring the interfaces up, this process
takes more than 5 minutes.
The below message is displayed on the screen:

A start job is running for LSB: Raise network interface [5:16]

After the timeout the systems works normally.

I'm using Lenny on a 64bit machine and the systemd init system.

# systemctl --version
systemd 215
+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ
-SECCOMP -APPARMOR


My /etc/network/interfaces:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.3
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 192.168.1.1 8.8.8.8


 It seams the problem is some race condition that results in a deadlock.
The systemd is waiting for a condition that never is satisfied.

Looking at the journalctl -alb - ( I just printed here the systemd and
networking specific messages)

Mar 27 09:50:14 vali systemd[1]: Found ordering cycle on basic.target/start
Mar 27 09:50:14 vali systemd[1]: Found dependency on paths.target/start
Mar 27 09:50:14 vali systemd[1]: Found dependency on acpid.path/start
Mar 27 09:50:14 vali systemd[1]: Found dependency on sysinit.target/start
Mar 27 09:50:14 vali systemd[1]: Found dependency on rpcbind.service/start
Mar 27 09:50:14 vali systemd[1]: Found dependency on
network-online.target/start
Mar 27 09:50:14 vali systemd[1]: Found dependency on network.target/start
Mar 27 09:50:14 vali systemd[1]: Found dependency on
networking.service/start
Mar 27 09:50:14 vali systemd[1]: Found dependency on basic.target/start
Mar 27 09:50:14 vali systemd[1]: Breaking ordering cycle by deleting job
paths.target/start
Mar 27 09:50:14 vali systemd[1]: Job paths.target/start deleted to break
ordering cycle starting with basic.target/start
Mar 27 09:50:14 vali systemd[1]: Found ordering cycle on basic.target/start
Mar 27 09:50:14 vali systemd[1]: Found dependency on sysinit.target/start
Mar 27 09:50:14 vali systemd[1]: Found dependency on rpcbind.service/start
Mar 27 09:50:14 vali systemd[1]: Found dependency on
network-online.target/start
Mar 27 09:50:14 vali systemd[1]: Found dependency on network.target/start
Mar 27 09:50:14 vali systemd[1]: Found dependency on
networking.service/start
Mar 27 09:50:14 vali systemd[1]: Found dependency on basic.target/start
Mar 27 09:50:14 vali systemd[1]: Breaking ordering cycle by deleting job
rpcbind.service/start
Mar 27 09:50:14 vali systemd[1]: Job rpcbind.service/start deleted to break
ordering cycle starting with basic.target/start
Mar 27 09:50:30 vali networking[745]: run-parts: executing
/etc/network/if-pre-up.d/wpasupplicant
Mar 27 09:50:31 vali networking[745]: Configuring interface lo=lo (inet)
Mar 27 09:50:31 vali networking[745]: run-parts --exit-on-error --verbose
/etc/network/if-pre-up.d
Mar 27 09:50:31 vali networking[745]: run-parts: executing
/etc/network/if-pre-up.d/bridge
Mar 27 09:50:31 vali networking[745]: run-parts: executing
/etc/network/if-pre-up.d/ethtool
Mar 27 09:50:31 vali networking[745]: run-parts: executing
/etc/network/if-pre-up.d/hostapd
Mar 27 09:50:31 vali networking[745]: run-parts: executing
/etc/network/if-pre-up.d/wireless-tools
Mar 27 09:50:31 vali networking[745]: run-parts: executing
/etc/network/if-pre-up.d/wpasupplicant
Mar 27 09:50:31 vali networking[745]: ip link set dev lo up
Mar 27 09:50:31 vali dbus[726]: [system] Activating via systemd: service
name='org.freedesktop.Accounts' unit='accounts-daemon.service'
Mar 27 09:50:31 vali networking[745]: run-parts --exit-on-error --verbose
/etc/network/if-up.d
Mar 27 09:50:31 vali networking[745]: run-parts: executing
/etc/network/if-up.d/000resolvconf
Mar 27 09:50:31 vali dbus[726]: [system] Activating via systemd: service
name='org.freedesktop.PolicyKit1' unit='polkitd.service'
Mar 27 09:50:31 vali networking[745]: run-parts: executing
/etc/network/if-up.d/avahi-autoipd
Mar 27 09:50:31 vali polkitd[832]: started daemon version 0.105 using
authority implementation `local' version `0.105'
Mar 27 09:50:31 vali dbus[726]: [system] Successfully activated service
'org.freedesktop.PolicyKit1'
Mar 27 09:50:31 vali accounts-daemon[734]: started daemon version 0.6.37
Mar 27 09:50:31 vali dbus[726]: [system] Successfully activated service
'org.freedesktop.Accounts'
Mar 27 09:50:31 vali networking[745]: run-parts: executing
/etc/network/if-up.d/avahi-daemon
Mar 27 09:50:31 vali kernel: vboxpci: IOMMU not found (not registered)
Mar 27 09:50:31 vali vboxdrv[735]: Starting VirtualBox kernel modules
...done.
Mar 27 09:50:31 vali networking[745]: run-parts: executing
/etc/network/if-up.d/ethtool
Mar 27 09:50:32 vali networking[745]: run-parts: executing
/etc/network/if-up.d/mountnfs
Mar 27 09:50:32 vali networking[745]: run-parts: executing
/etc/network

Re: LSB Raise network interface taking too long

[Michael Biebl]

Am 27.03.2015 um 18:50 schrieb Paulo Roberto:
 And you were right, removing the /etc/network/if-up.d/openntpd the problem
 was gone.
 
 I assume that this file that comes in the openntpd package should not exist.
 Am I correct?

It's a but in the openntpd package, I'd say.

In general, such hook scripts are evil stuff and should be avoided as
much as possible.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Upgrade wheezy-jessie: Network interface: eth0 (atl1c) shows excessive power consumption

[Rainer Dorsch]

Hi,

Am Samstag, 31. Januar 2015, 20:40:35 schrieb Reco:
  Hi.
 
 On Sat, 31 Jan 2015 15:07:58 +0100
 
 Rainer Dorsch m...@bokomoko.de wrote:
  it uses after the upgrade to jessie an excessive amount of power
  
  The battery reports a discharge rate of 9.75 W
  The estimated remaining time is 2 hours, 10 minutes
  
  Summary: 585.9 wakeups/second,  50.0 GPU ops/seconds, 0.0 VFS ops/sec and
  22.6% CPU use
  
  Power est.  Usage   Events/sCategory   Description
  
4.91 W  0.0 pkts/sDevice Network interface:
eth0 
  (atl1c)
 
 …
 
  Does anybody have an idea, how to debug this issue?
 
 Try disabling wake-on-lan on this interface, i.e.
 
 ethtool -s eth0 wol d

That does not change anything, I still get similar numbers:

Power est.  Usage   Events/sCategory   Description
  5.62 W  0.0 pkts/sDevice Network interface: eth0 
(atl1c)
  2.40 W 60.0%  Device Display backlight
  639 mW  0.4 pkts/sDevice Network interface: 
wlan0 (iwlwifi)
  309 mW  3.3 ms/s 105.8Interrupt  PS/2 Touchpad / 
Keyboard / Mouse
  237 mW 12.0 ms/s  72.9Process/usr/bin/konsole -
session 10e2d5d3650001422760019720029_1422822747_648972
  192 mW 22.3 ms/s  48.1Process/usr/bin/kmail -caption 
KMail
  189 mW 18.2 ms/s  63.9Processkwin -session 
10e2d5d3650001348178311003743_1422822747_727143
  173 mW 28.4 ms/s  36.2Process/usr/bin/plasma-desktop
  120 mW 22.8 ms/s  22.4Process/usr/bin/X :0 vt7 -br -
nolisten tcp -auth /var/run/xauth/A:0-pi14ma
 71.3 mW  1.3 ms/s  23.9Process[irq/44-iwlwifi]
 59.6 mW  0.9 ms/s  20.1Process/usr/sbin/mysqld --
defaults-file=/home/rd/.local/share/akonadi/mysql.conf --
datadir=/home/rd/.local/share/akonadi/db_data/ --so
 53.3 mW597.7 µs/s  18.2Interrupt  [45] i915
 39.7 mW153.5 µs/s  13.8Interrupt  [44] iwlwifi
 36.2 mW  0.8 ms/s  12.0Timer  hrtimer_wakeup
 27.3 mW253.4 µs/s   9.4Process[ktpacpi_nvramd]
 25.0 mW212.8 µs/s   8.6kWork  ieee80211_iface_work
 22.7 mW  0.7 ms/s   7.4Process/usr/bin/kaddressbook
 22.5 mW177.2 µs/s   7.7Process[rcu_sched]


even though eth0 is disabled and wake-on-lan as well

root@nanette:~# ifdown eth0 


ifdown: interface eth0 not configured   


root@nanette:~# ethtool -s eth0 wol d   

 
root@nanette:~#

If I unload the eth module

root@nanette:~# rmmod atl1c 
root@nanette:~#

the total power does not go down that significantly but more distributes on 
other components (e.g. Display backlight is now higher):

Summary: 497.1 wakeups/second,  9.6 GPU ops/seconds, 0.0 VFS ops/sec and 9.2% 
CPU use

Power est.  Usage   Events/sCategory   Description
  5.54 W  0.6 pkts/sDevice Network interface: 
wlan0 (iwlwifi)
  3.73 W 60.0%  Device Display backlight
  673 mW 24.0 ms/s 162.9Process/usr/bin/konsole -
session 10e2d5d3650001422760019720029_1422822747_648972
  469 mW  4.2 ms/s 127.1Interrupt  PS/2 Touchpad / 
Keyboard / Mouse
  152 mW 22.3 ms/s  18.3Process/usr/bin/X :0 vt7 -br -
nolisten tcp -auth /var/run/xauth/A:0-pi14ma
  142 mW  9.6 ms/s  38.7Processkwin -session 
10e2d5d3650001348178311003743_1422822747_727143
 91.1 mW 19.8 ms/s   3.9Process/usr/bin/plasma-desktop
 90.1 mW  1.3 ms/s  23.9Process[irq/44-iwlwifi]
 74.2 mW  0.9 ms/s  19.8Process/usr/sbin/mysqld --
defaults-file=/home/rd/.local/share/akonadi/mysql.conf --
datadir=/home/rd/.local/share/akonadi/db_data/ --so
 51.8 mW149.7 µs/s  14.4Interrupt  [44] iwlwifi
 49.7 mW479.8 µs/s  13.4Interrupt  [45] i915
 49.5 mW  0.7 ms/s  13.1Timer  hrtimer_wakeup
 35.5 mW221.9 µs/s   9.7kWork  ieee80211_iface_work
 32.0 mW  0.8 ms/s   8.1Process/usr/bin/kaddressbook
 31.6 mW251.8 µs/s   8.6Process[ktpacpi_nvramd]

Sounds like powertop is not measuring accurately

Upgrade wheezy-jessie: Network interface: eth0 (atl1c) shows excessive power consumption

[Rainer Dorsch]

Hi,

even though I do not use the eth0 interface

root@nanette:~# ifconfig 
eth0  Link encap:Ethernet  HWaddr 04:7d:7b:5f:06:cd  
  UP BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:5943 errors:0 dropped:0 overruns:0 frame:0
  TX packets:5010 errors:0 dropped:0 overruns:0 carrier:2
  collisions:0 txqueuelen:1000 
  RX bytes:4359690 (4.1 MiB)  TX bytes:695857 (679.5 KiB)

loLink encap:Local Loopback  
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:757 errors:0 dropped:0 overruns:0 frame:0
  TX packets:757 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:147821 (144.3 KiB)  TX bytes:147821 (144.3 KiB)

wlan0 Link encap:Ethernet  HWaddr 74:e5:0b:d3:d6:b4  
  inet addr:192.168.178.27  Bcast:192.168.178.255  Mask:255.255.255.0
  inet6 addr: fd00::76e5:bff:fed3:d6b4/64 Scope:Global
  inet6 addr: fe80::76e5:bff:fed3:d6b4/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:5050 errors:0 dropped:0 overruns:0 frame:0
  TX packets:4511 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:2776701 (2.6 MiB)  TX bytes:727802 (710.7 KiB)

root@nanette:~# 

it uses after the upgrade to jessie an excessive amount of power

The battery reports a discharge rate of 9.75 W
The estimated remaining time is 2 hours, 10 minutes

Summary: 585.9 wakeups/second,  50.0 GPU ops/seconds, 0.0 VFS ops/sec and 
22.6% CPU use

Power est.  Usage   Events/sCategory   Description
  4.91 W  0.0 pkts/sDevice Network interface: eth0 
(atl1c)
  2.41 W 73.3%  Device Display backlight
  998 mW568.0 rpm   Device Laptop fan
  693 mW 50.5 ms/s 169.7Processkwin -session 
10e2d5d3650001348178311003743_1422711531_152502
  245 mW 89.1 ms/s 121.9Process/usr/bin/kmail -session 
10e2d5d36500014223087450038740015_142271153
 72.1 mW 32.3 ms/s  36.7Process/usr/bin/plasma-desktop
 46.5 mW 21.7 ms/s  13.3Process/usr/bin/X :0 vt7 -br -
nolisten tcp -auth /var/run/xauth/A:0-6D3fMb
 28.8 mW  5.2 ms/s 110.8Interrupt  PS/2 Touchpad / 
Keyboard / Mouse
 11.4 mW  5.3 ms/s   3.5Processkdeinit4: konqueror 
[kdeinit] https://duckduckgo.com/?q=text%2Fhtmlt=k
 9.11 mW  2.2 ms/s  28.2Interrupt  [45] i915
 8.08 mW  1.6 ms/s  28.9Timer  hrtimer_wakeup
 6.50 mW  3.1 ms/s   1.3Process/usr/bin/konsole -
session 10e2d5d3650001422760019720029_1422711
 5.41 mW  0.9 ms/s  21.3Process[irq/44-iwlwifi]
 5.26 mW  1.1 ms/s  18.6Timer  tick_sched_timer
 4.85 mW  1.1 ms/s  15.9Process/usr/sbin/mysqld --
defaults-file=/home/rd/.local/share/akonadi/mysql.co
 3.69 mW  1.5 ms/s  0.05kWork  
ieee80211_sta_monitor_work
 3.63 mW 60.5 µs/s   2.8kWork  
iwl_bg_run_time_calib_work
 2.55 mW237.5 µs/s  12.5Process[rcu_sched]
 2.08 mW  1.0 ms/s   0.3Processksysguardd

Does anybody have an idea, how to debug this issue?

Thanks,
Rainer


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/25407464.HLkONeo3Tk@nanette

Re: Upgrade wheezy-jessie: Network interface: eth0 (atl1c) shows excessive power consumption

[Reco]

 Hi.

On Sat, 31 Jan 2015 15:07:58 +0100
Rainer Dorsch m...@bokomoko.de wrote:

 it uses after the upgrade to jessie an excessive amount of power
 
 The battery reports a discharge rate of 9.75 W
 The estimated remaining time is 2 hours, 10 minutes
 
 Summary: 585.9 wakeups/second,  50.0 GPU ops/seconds, 0.0 VFS ops/sec and 
 22.6% CPU use
 
 Power est.  Usage   Events/sCategory   Description
   4.91 W  0.0 pkts/sDevice Network interface: 
 eth0 
 (atl1c)
… 
 Does anybody have an idea, how to debug this issue?


Try disabling wake-on-lan on this interface, i.e.

ethtool -s eth0 wol d

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150131204035.74256efe054e7d3abf395...@gmail.com

Re: /etc/network/interface file auto reset.

[Andrei POPESCU]

On Sb, 20 sep 14, 14:02:43, Andrei POPESCU wrote:
 
 Further reading:
...
 http://www.dtcc.edu/cs/rfc1855.html

A kind soul pointed out to me off-list that this link is dead. Apologize 
for not checking, here is a link to the same document:
https://www.ietf.org/rfc/rfc1855.txt

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: /etc/network/interface file auto reset.

[Lisi Reisz]

On Saturday 20 September 2014 13:07:13 softwatt wrote:
 On 09/20/2014 02:02 PM, Andrei POPESCU wrote:
  On Sb, 20 sep 14, 09:58:22, softwatt wrote:
   Why is quoting always needed?
 
  Other readers might be missing previous messages (network delays,
  deleted it, etc.), but want to jump in now. Without any context they
  would be unable or could provide answers for a different question.

 Thanks for your time, that explains it well.
 (See? I've started using it ^)

:-))  
Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201409211200.33534.lisi.re...@gmail.com

Re: /etc/network/interface file auto reset.

[Lisi Reisz]

On Friday 19 September 2014 07:56:14 softwatt wrote:
 But that is not risk-free. What if the thing that's overwriting the file
 on startup dislikes not being able to write to the file and crashes?

 By the way, my solution would fail if the overwriting is happening after
 startup.

softwatt, do you think you could quote??  Conversations with you in are 
virtually impossible to follow because you don't quote anything and the 
thread keeps jumping.

Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201409200718.31109.lisi.re...@gmail.com

Re: /etc/network/interface file auto reset.

[Lisi Reisz]

On Friday 19 September 2014 15:57:38 Reco wrote:
 On Fri, 19 Sep 2014 19:38:23 +0500

 Muhammad Yousuf Khan sir...@gmail.com wrote:
  thinks for your input. but i want to investigate which process is doing
  this?

 Please do not top post.

Better top-posting than not quoting at all.  Well, less awful anyway!!

Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201409200720.00361.lisi.re...@gmail.com

Re: /etc/network/interface file auto reset.

[softwatt]

Why is quoting always needed?
Mail clients know which mail is a reply to which.



signature.asc
Description: OpenPGP digital signature

Re: /etc/network/interface file auto reset.

[Lisi Reisz]

On Saturday 20 September 2014 07:58:22 softwatt wrote:
 Why is quoting always needed?
 Mail clients know which mail is a reply to which.

Well, I find it very difficult to follow you, and at least one person has 
answered and said that he did not know the original question but...  Which 
encourages the thread to drift.

Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201409200837.04987.lisi.re...@gmail.com

Re: /etc/network/interface file auto reset.

[Reco]

 Hi.

On Sat, 20 Sep 2014 07:30:50 +0200
mikael Flood the...@gmail.com wrote:

 it might be due to some configuration management agent running on the
 system which dictates a sane state of /etc/network/interfaces.
 
 might be puppet or cfengine.

I don't have much experience with puppet, cfengine, chef or ansible,
but the way I understand it - all of them require correctly configured
network to function. So if one of those tools is used at OP's host -
it's used wrong way, definitely.

And, it's very suspicious that such tool works only on reboot. Still,
if it's a misbehaving management agent - audit should show it (unless,
of course, said management agent will turn off audit).

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140920124434.b74e474f38e5e61b8913f...@gmail.com

Re: [OT] /etc/network/interface file auto reset.

[Reco]

On Sat, 20 Sep 2014 07:20:00 +0100
Lisi Reisz lisi.re...@gmail.com wrote:

 On Friday 19 September 2014 15:57:38 Reco wrote:
  On Fri, 19 Sep 2014 19:38:23 +0500
 
  Muhammad Yousuf Khan sir...@gmail.com wrote:
   thinks for your input. but i want to investigate which process is doing
   this?
 
  Please do not top post.
 
 Better top-posting than not quoting at all. Well, less awful anyway!!

[1] teaches us that:

Because it messes up the order in which people normally read text.

 Why is top-posting such a bad thing?

 Top-posting.

 What is the most annoying thing in e-mail?


And I really don't understand why a friendly reminder about top posting
(with a quote of a relevant part of original e-mail, mind you) is evil,
yet driving a topic to the off-topic is good :) No offense meant, as
always.


[1] http://danielmiessler.com/blog/email-top-vs-bottom-posting/

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140920124947.0271aa2c23273928632bb...@gmail.com

Re: /etc/network/interface file auto reset.

[Andrei POPESCU]

On Sb, 20 sep 14, 09:58:22, softwatt wrote:
 Why is quoting always needed?
 
Other readers might be missing previous messages (network delays, 
deleted it, etc.), but want to jump in now. Without any context they 
would be unable or could provide answers for a different question.

 Mail clients know which mail is a reply to which.

This is also not guaranteed, since mail clients handle threading 
differently (if implemented at all), depending on their (mis)features 
and configuration.

I'm advocating that each message should be as much as possible 
self-contained, but not longer. In practice this means you should keep 
enough context so that your message can be read on its own, but delete 
everything else.

Keeping the correct order of conversation makes it also easier to read 
and will increase your audience.

Further reading:
http://www.netmeister.org/news/learn2quote.html
http://www.dtcc.edu/cs/rfc1855.html
http://www.catb.org/~esr/faqs/smart-questions.html

Hope this explains,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: [OT] /etc/network/interface file auto reset.

[mikael Flood]

On Sat, Sep 20, 2014 at 10:49 AM, Reco recovery...@gmail.com wrote:

 On Sat, 20 Sep 2014 07:20:00 +0100
 Lisi Reisz lisi.re...@gmail.com wrote:

  On Friday 19 September 2014 15:57:38 Reco wrote:
   On Fri, 19 Sep 2014 19:38:23 +0500
  
   Muhammad Yousuf Khan sir...@gmail.com wrote:
thinks for your input. but i want to investigate which process is
 doing
this?
  
   Please do not top post.
 
  Better top-posting than not quoting at all. Well, less awful anyway!!

 [1] teaches us that:

 Because it messes up the order in which people normally read text.

  Why is top-posting such a bad thing?

  Top-posting.

  What is the most annoying thing in e-mail?


 And I really don't understand why a friendly reminder about top posting
 (with a quote of a relevant part of original e-mail, mind you) is evil,
 yet driving a topic to the off-topic is good :) No offense meant, as
 always.


 [1] http://danielmiessler.com/blog/email-top-vs-bottom-posting/

 Reco


 --
 To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive:
 https://lists.debian.org/20140920124947.0271aa2c23273928632bb...@gmail.com



Hello,

Sorry if my earlier reply wasn't all that helpful.

A configuration management agent might not always need network connectivity
to carry out changes to a local system.
The desired state is downloaded from a server and then applied by a local
agent on the system (cfengine),
but the agent also saves states locally, in case the machine looses
connectivity. Normally the agent also
operates at intervals while the system is live (powered on), but it is also
possible it only applies the changes at boot-up.

True, audit should show what the cause behind changes to
/etc/network/interfaces.

-- 
//Yours sincerely Mikael Flood

Re: /etc/network/interface file auto reset.

[softwatt]

On 09/20/2014 02:02 PM, Andrei POPESCU wrote:
 On Sb, 20 sep 14, 09:58:22, softwatt wrote:
  Why is quoting always needed?
  
 Other readers might be missing previous messages (network delays, 
 deleted it, etc.), but want to jump in now. Without any context they 
 would be unable or could provide answers for a different question.
 

Thanks for your time, that explains it well.
(See? I've started using it ^)



signature.asc
Description: OpenPGP digital signature

Re: /etc/network/interface file auto reset.

[Cindy-Sue Causey]

On 9/19/14, Darac Marjal mailingl...@darac.org.uk wrote:

 Put this into /etc/network/interfaces.d/br0

allow-hotplug br0
iface br0 inet static
address 10.xx.xx.18
netmask 255.xx.xx.xx
network 10.xx.xx.0
gateway 10.xx.xx.3
broadcast 10.xx.xx.255
dns-nameservers 10.xx.xx.8
bridge_ports eth1
bridge_stp off
auto br0

 Now, if something clobbers your /etc/network/interfaces file, hopefully
 it won't touch the br0 file and that'll still come up fine :)


*GREAT* point I felt should see another go to help highlight for
fellow users who haven't discovered dot d (.d) directories yet. Just
made the connection myself couple weeks ago via /etc/grub.d.

Our dot d directories are a place where necessary personalizations
remain static for programs that reset configurations on a regular
basis. On another thread, someone mentioned they create a backup, if
not an entirely separate place, for their own /etc directory because
of its importance to them. Excellent place to focus a piece of
self-training on with respect to preserving the kinds of tweaks such
as is being discussed here..

PS Apologies in advance if this shows up twice. Had a dialup glitch
JUST as it was sending but not seeing it posted yet.

Cindy :)

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* I comment, therefore I am (procrastinating elsewhere) *


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAO1P-kCQG2iLZojYYzXrQM4V95BrLf=jgR_2=25ldq8rl-q...@mail.gmail.com

Re: /etc/network/interface file auto reset.

[Muhammad Yousuf Khan]

Thanks Reco, Cindy and all for useful comments. i will try all suggestion
next working day and will update you accordingly.

Thanks,
MYK

On Sat, Sep 20, 2014 at 6:10 PM, Cindy-Sue Causey butterflyby...@gmail.com
wrote:

 On 9/19/14, Darac Marjal mailingl...@darac.org.uk wrote:
 
  Put this into /etc/network/interfaces.d/br0
 
 allow-hotplug br0
 iface br0 inet static
 address 10.xx.xx.18
 netmask 255.xx.xx.xx
 network 10.xx.xx.0
 gateway 10.xx.xx.3
 broadcast 10.xx.xx.255
 dns-nameservers 10.xx.xx.8
 bridge_ports eth1
 bridge_stp off
 auto br0
 
  Now, if something clobbers your /etc/network/interfaces file, hopefully
  it won't touch the br0 file and that'll still come up fine :)


 *GREAT* point I felt should see another go to help highlight for
 fellow users who haven't discovered dot d (.d) directories yet. Just
 made the connection myself couple weeks ago via /etc/grub.d.

 Our dot d directories are a place where necessary personalizations
 remain static for programs that reset configurations on a regular
 basis. On another thread, someone mentioned they create a backup, if
 not an entirely separate place, for their own /etc directory because
 of its importance to them. Excellent place to focus a piece of
 self-training on with respect to preserving the kinds of tweaks such
 as is being discussed here..

 PS Apologies in advance if this shows up twice. Had a dialup glitch
 JUST as it was sending but not seeing it posted yet.

 Cindy :)

 --
 Cindy-Sue Causey
 Talking Rock, Pickens County, Georgia, USA

 * I comment, therefore I am (procrastinating elsewhere) *


 --
 To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive:
 https://lists.debian.org/CAO1P-kCQG2iLZojYYzXrQM4V95BrLf=jgR_2=25ldq8rl-q...@mail.gmail.com

Re: /etc/network/interface file auto reset.

[Muhammad Yousuf Khan]

I also apologies for my wrong posting style. actually i am not aware of
what top posting is. can any of you please tell me what top posting means
so that i can avoid this in future.


Thanks,
MYK

Re: [OT] /etc/network/interface file auto reset.

[Reco]

Hi.

On Sat, 20 Sep 2014 23:51:55 +0500
Muhammad Yousuf Khan sir...@gmail.com wrote:

 I also apologies for my wrong posting style. actually i am not aware of
 what top posting is. can any of you please tell me what top posting means
 so that i can avoid this in future.

You reply to the mail.

You write your reply above the original (the one you're replying to)
mail - that's top-posting.
You write your reply below the previous mail - that's bottom-posting.
You interleave your reply with the original mail - that's interleaved
posting.

Last style is preferred here. Second style is tolerated here. First
style (the one you're currently using) is considered bad manners. I
didn't set those customs, I merely follow them.

Also, this:

http://danielmiessler.com/blog/email-top-vs-bottom-posting/

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140920232624.2d90d528b9e6835d3de20...@gmail.com

/etc/network/interface file auto reset.

[Muhammad Yousuf Khan]

Hi guys,

i am using wheezy with libvirt virtualization i have configured a bridge
interface for that purpose.
i have statically set the bridge interface in interfaces file.
like this

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth1
allow-hotplug br0
#iface eth1 inet dhcp
#iface eth1 inet static
iface br0 inet static
address 10.xx.xx.18
netmask 255.xx.xx.xx
network 10.xx.xx.0
gateway 10.xx.xx.3
broadcast 10.xx.xx.255
dns-nameservers 10.xx.xx.8
bridge_ports eth1
bridge_stp off
auto br0


now when ever i restart the wheezy server i shows me something like this.
auto lo
iface lo inet loopback
iface br0 inet dhcp
   bridge_ports eth1
bridge_stp off
auto br


and eventually my connection gets broken.
Please help.

Thanks,
MYK

Re: /etc/network/interface file auto reset.

[softwatt]

I have no idea how to solve the problem itself, someone else might help
you there.

But here's a way to bypass the problem by telling Debian to overwrite
the file on each startup. It might work.

Copy the file you want to preserve to somewhere else.
In this example I've copied etc/network/interface to /opt/interface.


Now, in /etc/rc.local add this line:
cp /opt/interface /etc/network/interface

I hope this helps.



signature.asc
Description: OpenPGP digital signature

Re: /etc/network/interface file auto reset.

[Reco]

 Hi.

On Fri, 19 Sep 2014 09:46:15 +0300
softwatt softw...@gmx.com wrote:

 I hope this helps.
 

chattr +i /etc/network/interfaces

will prevent overwriting the file with much less hassle.

PS Have no idea on the original problem.

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140919105156.1f02f8dc447f25c0e20a1...@gmail.com

Re: /etc/network/interface file auto reset.

[softwatt]

But that is not risk-free. What if the thing that's overwriting the file
on startup dislikes not being able to write to the file and crashes?

By the way, my solution would fail if the overwriting is happening after
startup.



signature.asc
Description: OpenPGP digital signature

Re: /etc/network/interface file auto reset.

[Reco]

On Fri, 19 Sep 2014 09:56:14 +0300
softwatt softw...@gmx.com wrote:

 But that is not risk-free. What if the thing that's overwriting the file
 on startup dislikes not being able to write to the file and crashes?

Look at it from the different angle -
overwriting /etc/network/interfaces is wrong, no sensible process
related to the boot should do it. Hence in the case of the process crash
it's trivial to locate and purge such process.

Which lead me to another point - crashing due to inability to overwrite
some file is a terrible programming practice. Such errors should be
catched and dealt with gracefully. Using a process with such code
quality in a boot sequence is obviously wrong.

I agree that there're scenarios that could lead to the unbootable
system in such circumstances. Therefore an access to the console is
crucial. But, since OP already loses network connectivity due to the
nature of the problem and can fix it by hand - OP has an access to the
console anyway.

Besides, a simple overwriting /etc/network/interfaces from
the /etc/rc.local won't do any good by itself, as the network is
configured at that time already, and it's configured wrong way. An
additional sequence of 'ifdown br0; pkill dhcp; ifup br0' is needed at
least.

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140919112826.c24872f970aa8f915c258...@gmail.com

Re: /etc/network/interface file auto reset.

[softwatt]

Thanks for explaining. Debian guys teach me something new every day.



signature.asc
Description: OpenPGP digital signature

Re: /etc/network/interface file auto reset.

[Darac Marjal]

On Fri, Sep 19, 2014 at 11:37:38AM +0500, Muhammad Yousuf Khan wrote:
Hi guys,
i am using wheezy with libvirt virtualization i have configured a bridge
interface for that purpose. 
i have statically set the bridge interface in interfaces file. 
like this

As another alternative, if you have ifupdown 0.7.41 or later, you can
put files into /etc/network/interfaces.d/ and they'll get included. So,
leave this in /etc/network/interfaces:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth1
#iface eth1 inet dhcp
#iface eth1 inet static

Put this into /etc/network/interfaces.d/br0

allow-hotplug br0
iface br0 inet static
        address 10.xx.xx.18
        netmask 255.xx.xx.xx
        network 10.xx.xx.0
        gateway 10.xx.xx.3
        broadcast 10.xx.xx.255
        dns-nameservers 10.xx.xx.8
        bridge_ports eth1
        bridge_stp off
        auto br0

Now, if something clobbers your /etc/network/interfaces file, hopefully
it won't touch the br0 file and that'll still come up fine :)


now when ever i restart the wheezy server i shows me something like this.
auto lo
iface lo inet loopback
iface br0 inet dhcp
       bridge_ports eth1
        bridge_stp off
        auto br
and eventually my connection gets broken. 
Please help.
Thanks,
MYK


signature.asc
Description: Digital signature