Web lists-archives.com

Re: Inconsistent predictable interface names

On Wed, Aug 30, 2017 at 04:12:16PM +0300, Reco wrote:
> 	Hi.
> On Wed, Aug 30, 2017 at 08:39:44AM -0400, Cindy-Sue Causey wrote:
> > On 8/29/17, Reco <recoverym4n@xxxxxxxxx> wrote:
> > 
> > 
> > I left everything in there in case somehow it already says "yes or
> > no". Is it possible that's previously declared somewhere, possibly
> > maybe in user configuration files that would carry over from upgrade
> > to upgrade?
> OP's e-mail says to this:
> > > I am experiencing an odd issue with a new install of Stretch.
> My e-mails assumed that there was no upgrade.
> 'udevadm info' should've shown such stray configuration files BTW, hence
> 'trie on-disk' remark.

Yep, this was a new install. Even though I tend to reuse old configurations
from previous installs, this very much happend with an untouched new
install (only deviation from a "default" was xfce instead of gnome).
I disabled the NM but at that time the names were already like they are
right now. 

BTW. all those "try on disk" were sent to stderr and I piped only the
stdout into my previous mail, that's why they were missing.

> > Maybe like something manually altered via a network
> > manager at some point... or something....? :)
> That's possible. Network Manager's ability to change MAC address of WLAN
> (for AP scanning), or, say, machanger intervention can lead to funny
> results if "Predictable" NIC Names are enabled. I haven't seen it
> manifested in NIC renaming though.

That was my initial thought.

> It should not be possible in this case (all NICs are PCI devices) since
> "Predictable" NIC Names should set by udev from initrd long before root
> filesystem is mounted and things like Network Manager have a chance to
> interfere.

Yes, and I see that in dmesg happening for eth0. However that does not
happen for the wlan0. I can see the firmware being loaded but no name
changing to predictable pattern.



Henning Follmann           | hfollmann@xxxxxxxxxxxxxxx